Summary

  • On 25 February 1993, Marc Andreessen proposed an optional IMG element whose required SRC would tell a browser which bitmap or pixmap to fetch and place inside a document.
  • The proposal separated that displayed resource from a hyperlink destination: an image could appear on its own, or an A element could wrap it and supply a different target. HTML 2.0 later kept that distinction while adding ALT and image-map semantics.

Today it is easy to treat a picture inside a page as part of the page’s grammar. In February 1993, the more precise question was how an HTML document should name that picture, where the browser should put it, and what a click on it should do. Marc Andreessen’s message to the WWW-TALK list answered those questions with one short tag: IMG.

The proposal did not claim to invent pictures on computer screens, or even to be the first way a browser could display one. It addressed a narrower interface problem. A link already had a job: connect an anchor to another destination. Andreessen wanted a document to be able to request an image at a particular point in its text without making that image’s address the destination of a link.

His 25 February note called the element optional and made SRC="url" its required argument. The URL named a bitmap or pixmap that the browser would try to retrieve over the network and interpret as an image. The browser would place the result where the tag occurred. The tag needed no closing form; it was a standalone reference.

Andreessen also described how display and navigation could be combined without becoming the same operation. An IMG could sit inside an anchor. In that case, the picture would respond to activation like linked text. Outside an anchor, it was simply an image. The browser could show a picture in a paragraph, while a separately declared link could send the reader somewhere else.

That distinction drew an immediate design question. On 26 February, Jim Davis asked why the new element used SRC rather than HREF, and suggested that an element might identify a content type as well. Andreessen answered that he wanted to avoid overloading HREF: the image source and the anchor destination described different things. If a picture needed to be clickable, the markup could place IMG SRC inside A HREF.

The choice was more than a naming preference. SRC told the browser what to retrieve for rendering. HREF told an anchor where activation should lead. Keeping them separate let an author reuse one image with different destinations, show an image without making it a link, or make the image a link without claiming that the image file itself was the destination. The document could express both relationships at once.

The list did not agree that an image-specific element was the only sensible design. Davis proposed a way to identify non-image content. On 1 March, Dave Raggett argued for considering a more general treatment of media, MIME typing and format negotiation instead of adding separate hooks one medium at a time. In March, Guido van Rossum discussed the scope of general INCLUDE or EMBED mechanisms, including the risk of one embedded document recursively including another.

Those objections identified a real trade-off. A specialized image element gave browser authors a small, implementable feature. A general external-content mechanism promised a wider model, but raised harder questions about types, recursion, layout and how an unfamiliar browser should behave. The archive shows the disagreement; it does not record one message that settled it for everyone.

Andreessen’s original proposal left part of that work to browser makers. He named XBM and XPM as useful formats but said browsers should have flexibility in what they supported. If X Mosaic could not interpret a format, it would show a default bitmap placeholder. He also wrote that the feature was already working internally in X Mosaic and was required for that browser. That is an attributed report of internal implementation. It does not show when a public build first shipped the feature, how many people used it, or whether other browsers adopted it because of this proposal.

By 1995 the working group was still refining what should happen when an image could not or should not be processed. An HTML Working Group discussion proposed wording that allowed a user agent to process ALT text instead of the resource named by SRC, including because of processing constraints or user preference. A participant pointed out that an omitted ALT and an explicitly empty value were different choices. This was not a guarantee that every author supplied useful text; it was a debate about how the specification should describe a fallback.

RFC 1866, published in November 1995 as HTML 2.0, formalized the IMG element. It defined SRC as the image resource URI and ALT as text to use in place of that resource, for example because of processing constraints or user preference. It also defined alignment and ISMAP. The specification drew a crisp line between an image and a link: IMG graphics were not anchors. If a graphic was essential, it should be referenced from an A element; if it was not essential, IMG was appropriate. Yet its example still put an IMG inside an A. The two rules fit together: the image alone does not create navigation, but an anchor can make it activatable.

The spec also marked the limits of the early proposal. The February message had pointed to XBM and XPM and left browser support open. RFC 1866 said that, in practice, image resources were typically GIF or JPEG. It did not add a CONTENT-TYPE attribute to IMG; the element named a resource, while the browser and the returned media type determined whether it could be displayed. The author could supply alternative text, but the DTD made ALT optional.

The historical change was therefore not simply “the Web got pictures.” The proposal made a picture a separately addressed resource that could occupy a position in a document without taking over the meaning of a hyperlink. The later standard kept that composition, described a fallback, and made the boundary between display and activation explicit. The records support that specific design history. They do not establish that IMG alone made the Web popular, that it was the first graphical-browser feature, or that every implementation behaved alike.

Sources