摘要

  • 1993 年 2 月 25 日，Marc Andreessen 提议加入可选的 IMG 元素，以必需的 SRC 指定浏览器要获取并显示的位图或像素图。
  • 图像可以只是文档内容；若要让它可点击，作者可再用 A 元素包住它，并单独指定链接目的地。HTML 2.0 后来保留了这种组合方式，并为 ALT 文字规定了替代用途。

这份提案处理的不是“如何让屏幕第一次显示图片”。它面对的是更窄、也更具体的问题：超文本文件如何在正文某处引用图像，同时不把图像文件的地址误作点击后要去的地方。1993 年 2 月 25 日，Marc Andreessen 在 WWW-TALK 邮件列表提出了一个简短答案：增加独立的 IMG 标签。

这个元素是可选的，必须带有 SRC="url"。浏览器要尝试从网络取回该 URL 指向的位图或像素图，并在标签所在位置呈现。它不需要闭合标签。文档因此可以要求显示一项资源，而不用把该资源本身定义为超链接。

图像能否点击，取决于另一层标记。Andreessen 说，IMG 可以放在锚点内部；此时图像像链接文字一样响应激活。若没有外层锚点，IMG 只负责显示，不会自行说明下一步导航到哪里。作者可以把图像放入段落，也可以让它成为某个链接的可点击内容。

第二天，Jim Davis 追问为什么要用 SRC 而不是 HREF，并提出应否标明内容类型。Andreessen 的回答抓住了语义边界：不应让 HREF 同时承载来源和链接目的地。SRC 告诉浏览器要取回什么来显示；A HREF 告诉浏览器激活后要前往哪里。像 <A HREF="destination"><IMG SRC="picture"></A> 这样的结构把两种关系并列表达，而没有把它们混为一谈。

这不是无关紧要的命名偏好。同一张图可以不带链接地显示，可以链接到说明页，也可以在多处复用而指向不同页面。编辑者改变点击目的地时，不必同时改图像来源。反过来，某个图像资源即使并非导航对象，也能在文档中占有位置。

讨论很快延伸到图像之外。3 月 1 日，Dave Raggett 提议考虑通用的外部媒体处理机制，包括 MIME 类型与格式协商，而不是逐种媒体增加专用标签。3 月，Guido van Rossum 讨论 INCLUDE 或 EMBED 等一般机制的边界：如果被嵌入的文件还能继续嵌入其他文件，递归带来的范围与处理问题该如何约束。通用方案涵盖更多资源，却也需要回答类型识别、页面布局、嵌入层级和旧浏览器行为等问题。邮件档案保留了这些分歧，但没有一封信可以被当作所有人的最终裁决。

Andreessen 的原始提案把部分兼容工作留给浏览器作者。他举出 XBM、XPM 作为有用格式，却表示浏览器应能自行选择支持范围。如果 X Mosaic 无法解释某种格式，就显示默认位图占位符。他还写道，该功能当时已在 X Mosaic 内部运行，并且是这个浏览器所需要的。这只能作为他对内部实现状态的陈述；它没有说明功能首次进入公开版本的日期、实际使用规模，或其他浏览器为何采用它。

到 1995 年，参与者仍在讨论图像不可处理时应向读者提供什么。6 月的 HTML 工作组邮件讨论了何时可以用 ALT 的值代替 SRC 所指资源，例如出于处理限制或用户偏好；其中也有人指出，省略 ALT 与明确写成空值并不相同。规范讨论替代文字的意义，并不意味着每个作者都写出了有用描述。

1995 年 11 月发布的 RFC 1866（HTML 2.0）正式定义 IMG、SRC、ALT、ALIGN 和 ISMAP。SRC 是图像资源 URI；ALT 是在不处理图像时可替代它的文字。规范也明确写出，IMG 图形本身不是锚点：如果图像内容至关重要，应从 A 元素引用；非必要图形则可用 IMG。RFC 的例子仍允许用 A 包住 IMG。两条规则并不矛盾：图像本身不创建导航，但锚点可以让它成为可激活的链接内容。

RFC 也呈现了设计的变化。1993 年提案提到位图和像素图，把格式支持留给浏览器；1995 年规范则说常见图像资源通常是 GIF 或 JPEG。它没有为 IMG 新增 CONTENT-TYPE 属性：标记命名资源，浏览器再根据收到的内容判断能否显示。ALT 提供了替代通道，但 DTD 并未要求作者填写。

因此，这段历史不只是“网页有了图片”。提案让图像成为可单独寻址、可嵌入正文的资源，同时不让它天然等同于超链接。后来的标准延续了这种组合，并把显示与激活的界线写得更清楚。现有材料支持这条具体的设计脉络，却不足以证明 IMG 单独带动了 Web 普及、Mosaic 是首个图形浏览器，或各浏览器都以同样方式实现。

来源