1995–1998: Interactive Web Pages Before “Web APIs” Had a Name

In the mid-to-late 1990s, developers already wanted something that looked a lot like modern media integration:

• A simple way to place media in a page.
• A way to control playback (play, pause, seek) from code.
• A way to respond to user actions (click, load, error).
• A consistent experience across browsers and operating systems.

But “web APIs” as we now think of them—stable, standardized JavaScript interfaces with consistent security models—were still emerging. The building blocks were there, though, and they mattered:

• HTML forms established a declarative UI-to-network pattern.
• CGI popularized server-generated dynamic responses and file streaming.
• Early browser scripting introduced event-driven programming inside documents.
• Embeds and plugins demonstrated client-side playback, but outside the browser’s native control plane.

Forms + CGI: The Earliest “Media API” Was Often a Download Link

Before browsers offered native, scriptable playback, media on the web commonly behaved like a file transfer problem. A page might present:

• a link to an audio file,
• a form that requested a particular bitrate or format, or
• a CGI endpoint that generated a playlist-like response based on user input.

In other words, interactivity lived at the boundary between forms and server programs. The browser’s role was to gather inputs and request a resource; the server’s role was to decide what to send back.

This shaped a durable assumption: the browser could initiate retrieval, but it wasn’t necessarily responsible for deep, user-friendly playback. HTML5 media APIs later inverted that assumption by making playback a first-class browser feature—but they still preserved the “resource request” model. When you set src on a media element today, you’re echoing that old web contract: declare a resource, let the user agent fetch it, and update the UI based on loading state.

Browser Scripting Appears: Events, State, and the Desire to Control Media

As browser scripting became practical in the mid-1990s, developers gained an in-page way to respond to user actions. That’s the heart of media APIs today: a media element emits events, exposes state, and allows method calls.

But during 1995–1998, that model was inconsistent and fragmented. Scripts could change images, validate forms, open windows, and react to basic events, yet media playback was commonly handled by external applications or plugins. Developers still tried to build “controls” around media using the tools they had:

• buttons that launched a helper app via a link,
• UI that swapped embedded objects, or
• forms that hit CGI scripts to generate alternative media URLs.

Even when this worked, it was not truly browser-native. It looked interactive, but the state lived elsewhere—inside a plugin, a helper app, or the server. The frustration from this era is part of why HTML5 media APIs became so method-and-event oriented: developers wanted the playback state to be something the browser could expose reliably to JavaScript.

Embed and Object: The Plugin Era’s “API Surface” (and Its Limits)

By the late 1990s, embedding media often meant relying on browser plugin ecosystems using elements like <embed> and, increasingly, <object>. This was a pivotal step in web API history because it introduced a pattern developers still recognize:

1. Declare a media-like thing in markup.
2. Pass parameters to it.
3. Let it render inside the document.
4. Hope it behaves consistently across browsers.

The pattern was familiar, but the outcomes weren’t. Plugins differed in capabilities and security assumptions. Some exposed scripting hooks; others did not. Some relied on proprietary interfaces and browser-specific quirks. And crucially, the browser itself didn’t own the playback pipeline, so it couldn’t standardize buffering behavior, error reporting, or accessibility-friendly controls.

HTML5 media APIs can be read as a direct response to those limits: “What if the browser did the playback itself, and the scripting interface was standardized?”

Why the Mid-1990s Matter to HTML5 Media APIs

To connect 1995–1998 to HTML5, focus on the API design lessons that were learned early, sometimes the hard way.

1) Declarative first, then scriptable control

Forms were declarative. You described inputs and a target URL. Scripting later enhanced them. HTML5 media follows that same ladder: start with <video src>, then add scripted control when needed.

2) A predictable event model is non-negotiable

Early dynamic pages made developers depend on events (load, click, submit). Plugin media often hid or invented its own event system. HTML5 standardized media-related events so developers could build controls, analytics, and UI that weren’t tied to a vendor’s plugin.

3) State belongs in the browser if you want consistency

In 1995–1998, “state” might have lived on the server (CGI session logic), inside a helper application, or in a plugin. That made it hard to build reliable experiences. Browser-native playback moved buffering state, ready state, and error state into the user agent, where APIs can read it consistently.

4) Security and user intent must gate playback

Even early on, browsers had to balance power and safety. As scripting matured, it became obvious that not every action should be silent or automatic. Modern autoplay policies and user-gesture requirements echo this long-running theme: interactive features need guardrails.

From “Media as a File” to “Media as a DOM Element”

In the 1995–1998 window, developers usually treated media as a downloadable artifact or an embedded black box. The big conceptual leap that HTML5 formalized later was treating media as a first-class DOM element with a standard JavaScript interface.

If you want a concrete, modern reference point for what that interface looks like today, the MDN documentation for HTMLMediaElement is a good authoritative starting place. It shows how playback methods, properties, and events are unified under a consistent API surface—exactly what the plugin era struggled to provide.

Looking back, you can see the web’s evolution as a series of migrations:

• From server-generated interactions (CGI + forms) → to client-side interactivity (scripting + DOM).
• From proprietary embeds → to standardized elements.
• From external playback → to browser-native playback.

What This Era Still Teaches Modern Developers

Even if you never touch CGI or plugin embeds, the 1995–1998 period is still relevant when you design or use web APIs today:

• Progressive enhancement works: start with a baseline experience, then layer advanced controls and telemetry.
• Standardization is a product feature: inconsistent behavior is more costly than a slightly less “powerful” API that works everywhere.
• APIs shape UX: when the browser owns media playback, it can integrate accessibility, power management, full-screen behavior, and network heuristics in a way plugins could not.

If you’re exploring automation, testing, or API-driven workflows across different browsers, it helps to remember this history: the modern web’s “native” surfaces exist because earlier approaches fragmented developer control. For more experiments and write-ups that connect automation practice with web platform behavior, you can browse resources at AutomatedHacks.com.

FAQ: HTML5 Media APIs and the 1995–1998 Web

Did browsers in 1995–1998 have anything like the HTML5 media APIs?

Not in the standardized, browser-native sense. Media often relied on external helper applications or plugins, and scripting control (when present) was typically proprietary and inconsistent.

Why talk about CGI and forms in a post about media playback?

Because they defined the early “interaction contract” of the web: user input leads to a request for a resource. HTML5 media elements still follow this model—only now the browser also owns playback state and control.

What was the biggest limitation of plugin-based media embeds?

Plugins weren’t part of a single, stable web standard. Their APIs, behaviors, and security models varied, which made cross-browser development and long-term compatibility difficult.

What is the modern equivalent of “controlling media” in JavaScript?

Today, you control media through standardized interfaces (methods, properties, and events) exposed by media elements. A central reference is the HTMLMediaElement API documentation.