实现和标准总是在不断地相互牵制。你不愿意实现一个未完成的标准，因为你不知道你的最终实现是不是能够很好的符合这个标准。同时，如果没有相关实现，你也不愿意去完成这个标准，因为你需要从实现那里获得用户的反馈，从而设计更好的标准。于是，这二者似乎要一直这么耗下去，直到我们找到一个平衡点。本篇即是来告诉你，HTML5 是如何达到今天这一地步的。
MIME 类型
这个系列是关于 HTML5，而不是之前的 HTML 版本，也不是任何版本的 XHTML。但是，为了更好地了解 HTML5 的历史和制定 HTML5 的动机，你需要先了解一下技术细节，尤其是 MIME 类型。
浏览器每一次请求一个页面的时候，web 服务器都会在实际内容之前发送一个“头”，也就是 header。这些头信息通常是不可见的，通过一定的 web 开发工具可以让你看到它们。头信息是非常重要的，因为它会告诉浏览器如何去解释接下来的内容。其中最重要的一个头叫做 Content-Type，它看起来像是：
Content-Type: text/html
“text/html”叫做这个页面的“内容类型（content type）”，或者是“MIME 类型”。这个头是唯一一个用于判断接下来的内容是什么类型的，因此决定了这些资源究竟需要如何渲染。图片有它们自己的 MIME 类型，例如 JPEG 图片是 image/jpeg，PNG 图片是 image/png 等等。JavaScript 也有自己的 MIME 类型，CSS 也有。所有资源都有自己的 MIME 类型。在一定程度上我们可以说，web 实际上就是一大堆各种 MIME 类型的资源。
当然，实际情况要比这复杂得多。第一代 web 服务器（大约是 1993 年的时候）根本不会发送 Content-Type 头，因为那时候没有这个概念（这是在 1994 年提出的）。为了兼容 1993 年的服务器，很多流行的 web 服务器都会在特定情形下忽略 Content-Type 头（这被成为内容嗅探 content sniffing）。但是，作为新一代的规则，你现在在 web 上看到的所有东西——HTML 页面、图片、脚本、视频、PDF，所有一切拥有 URL 的东西——都有自己的 Content-Type 头定义的 MIME 类型。
好了，现在你所需要了解的就这么多。我们先来看看别的东西。
标准是如何制定的？
为什么我们有一个<img>元素？这不是一个你经常听到的问题。显然，有人创造了它！这些东西不会无缘无故地出现。每一个元素，每一个属性，你所使用的 HTML 的每一种功能都是由某人创造的，决定它们需要如何工作，如何编写。这些人不是上帝，也不是完美无瑕的人。他们当然是很聪明的人，但是记住，也不过是人！
公开指定标准的一大好处是，你可以回溯过去去找到上面问题的答案。这些讨论会出现在公开的邮件列表上。所以我们能够搜索一下这些邮件列表，来寻求“为什么我们有一个<img>元素？”的答案。我们必须回到 World Wide Web Consortium （W3C）出现之前，回到 web 的最早期，回到那个你自己都可以用手指数清有几个 web 服务器的年代。
（注意：以下引用有一些技术错误，不过在这里还是保持原状。）
1993年2月25日，Marc Andreessen 写道：
我想有一个新的 HTML 标签：IMG。它的必须属性是 SRC="url"。这可以为浏览器标记出一个位图或者其他图像，可以嵌入到文本中。例如我们可以这么写：（这个标签不需要关闭，仅仅是一个单独使用的标签。）
这个标签可以像其他标签一样嵌入到锚 anchor 中。当嵌入到锚中时，它就变成了一个图标 icon，就像是一个标准的文本锚一样可以被激活。
浏览器应该可以灵活支持所需要的图像格式。Xbm 和 Xpm 就是不错的选择。如果浏览器不能显示指定的格式，那么使用任何东西替代一下就好了（X Mosaic 可以显示一个默认的位图做占位符）。
这是 X Mosaic 必须的功能。我们已经有这么一个实现，至少可以内部使用。我希望公开征求一下意见，看看怎么在 HTML 中实现。如果你有什么好主意，请告诉我。我知道对于图像格式这部分而言是比较模糊的，除此之外我觉得没有什么问题，让浏览器实现就好了，然后等待一个完美的解决方案（或许是 MIME）。
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
说明一下，Xbm 和 Xpm 是 Unix 系统上流行的图像格式。“Mosaic” 是最早的浏览器之一（“X Mosaic” 是运行在 Unix 系统上的版本）。在 1993 年早期 Marc Andreessen 写下这个邮件的时候，他还没有创建那个让他闻名于世的 Mosaic Communications Corporation，当然也没有这个公司的产品“Mosaic Netscape”。作为开发人员，你应该听说过它们后来的名字“Netscape Corporation”和“Netscape Navigator”。
“或许是 MIME”是一种内容协商 content negotiation，意思是由客户端（例如浏览器）告诉服务器（例如 web 服务器），它支持哪些资源（例如 image/jpeg），然后服务器返回给客户端所支持的格式。制定于 1991 年的 HTTP 协议原始版本（这个版本直到 1993 年才被实现）没有办法告诉服务器客户端究竟支持哪些格式的图片，因此 Marc 才会这么说。
几小时之后，Tony Johnson 回复道：
在我 Midas 2.0 中有一个很类似的实现（使用的是 SLAC 实现），除了名字不同。它还有一个属性 NAME="name"。这个东西很像你说的 IMG 标签，例如：
name 属性的用途是让浏览器能够有一系列内置图片。如果图片的 name 和浏览器内置图片的名字相同，那么浏览器就直接使用内置图片，而不是从网络上再去下载新的。name 对于“线模式”的浏览器也是一种指示，用于告诉浏览器在图片的位置要使用哪种符号。
我不关心标签名或者属性名，但是我们应该让名字保持一致。我不太喜欢缩写词，所以希望是 IMAGE= 或者是 SOURCE= 这种名字。我想也应该有一个 ICON，用于指示一种小的图片，不过 ICON 好像已经使用了？
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
Midas 是另一个早期的浏览器，类似于 X Mosaic。它是跨平台的，可以同时运行在 Unix 和 VNS 上。“SLAC” 指的是 Stanford Linear Accelerator Center，现在是 SLAC National Accelerator Laboratory，是美国第一个 web 服务器主机（事实上是欧洲以外的第一个 web 服务器）。当 Tony 写下这个邮件的时候，SLAC 已经是 WWW 的老前辈，已经托管了 5 个页面 441 天。
Tony 继续写道：
我们正在讨论新标签的问题，于是我想到另一个类似的标签，希望能够在 Midas 2.0 中使用，类似于：
这个标签用于在第一个文档中的该标签位置引入第二个文档。事实上，这个所谓的文档可以是任何东西，但主要目的在于嵌入图片。另外，关于 HTTP2 如何搭在嵌入文档的格式应该是另外一个独立的议题。
<INCLUDE HREF="...">
HTTP2 指的是 1992年定义的基本 HTTP，在1993年早期仍然没有被广泛实现。后来三年内，HTTP2 草案修订为“HTPP1.0”。HTTP1.0 包含了内容协商的请求头，也就是前面说的“或许是 MIME”那句话。
Tony 继续写道：
另外一个替代是：
我不想在 <A> 标签中加入太多的功能，但这里主要是为了兼容不支持 INCLUDE 参数的浏览器。能够理解 INCLUDE 的浏览器将会使用要求包含的文档（例如图片）在标签的文本位置（这里就是 See photo）进行替换，另外的浏览器则直接忽略 INCLUDE 标签。
<A HREF="..." INCLUDE>See photo></A>
这一提案从来没有被实现，但它的思想被添加到 Marc 的 <IMG> 标签中，所谓无法显示图片时的替代文本。几年之后，这一特性被添加进 <img alt> 属性，Netscape 把它解释为一种浮动提示。
