MIME Type 引出的两难困境-网页设计,HTML/CSS

一切从一个糟糕的浏览器开始，它彻底不支持 xhtml。

　　 什么是 mime type？

　　为何这么说呢？首先，咱们要了解浏览器是如何处理内容的。在浏览器中显示的内容有 html、有 xml、有 gif、还有 flash……那么，浏览器是如何区分它们，绝对什么内容用什么形式来显示呢？答案是 mime type，也就是该资源的媒体类型。

　　媒体类型一般是经过 http 协议，由 web 服务器告知浏览器的，更准确地说，是经过 content-type 来表示的，例如:

content-type: text/html

　　表示内容是 text/html 类型，也就是超文本文件。为何是“text/html”而不是“html/text”或者别的什么？mime type 不是我的指定的，是通过 ietf 组织协商，以 rfc 的形式做为建议的标准发布在网上的，大多数的 web 服务器和用户代理都会支持这个规范 (顺便说一句，email 附件的类型也是经过 mime type 指定的)。

　　一般只有一些在互联网上得到普遍应用的格式才会得到一个 mime type，若是是某个客户端本身定义的格式，通常只能以 application/x- 开头。

　　xhtml 正是一个得到普遍应用的格式，所以，在 rfc 3236 中，说明了 xhtml 格式文件的 mime type 应该是 application/xhtml+xml。

　　固然，处理本地的文件，在没有人告诉浏览器某个文件的 mime type 的状况下，浏览器也会作一些默认的处理，这可能和你在操做系统中给文件配置的 mime type 有关。好比在 windows 下，打开注册表的“hkey_local_machinesoftwareclassesmimedatabasecontent type”主键，你能够看到全部 mime type 的配置信息。

　　 浏览器处理 xhtml 和 html 有什么区别？

　　html 的语法过于随意了，有许多简写，标记不匹配的复杂状况，同时长期 web 发展下来积累下来了许多错误的用法??好比一个文档里彻底没有 标记??但浏览器仍是得支持它，可想而知，为了支持这些“tag soup”??也就是咱们所说的那些，乱成一锅粥的标签??浏览器要很费力地去猜想一段标记的意思，努力以用户指望的形式表达出来。一句话说，虽然 html 4.01 容许你用语义化、结构化的、内容与表现分离的方法来书写标记，但因为它沿袭了 html 这种格式，使得浏览器对于凡是 mime type 为“text/html”的文件，都得采用一种很是费劲的方法去处理，这对于 web 的发展是很不利的。

　　再说除了浏览器，还有许多其余的用户代理要阅读 html：纯文本的浏览工具、读屏器等等。

　　创造 xhtml，很大一部分缘由正是要经过 xml 从新严格地规范一遍标记，让这些用户代理能够以一种更简便的方式来解析这些标记。所以，xhtml 这种新的格式，天生就要求内容的发布者必须以严格的方式来标记本身的文档。

　　固然，xhtml 对于内容提供者也有好处，此处先不展开，详见下文。

　　 mime type 与之又有什么关系？

　　把前两节的内容合起来，你显然能够发现：一个正常支持 xhtml 的浏览器会根据服务器提供的 mime type 是 text/html 仍是 application/xhtml+xml 来区分获取到的内容是 html 仍是 xhtml，对这两种格式，分别以两种不一样的方式来解析文档，后者解析起来要严格得多，但对于用户代理开发者和内容提供者都有很大的好处。

　　那么，那些浏览器正常的支持了 xhtml 呢？答案是 mozilla、基于 mozilla 的浏览器如 netscape 7 和 firefox、较新版本的 opera 和 safari 等等。但不包括 microsoft internet explorer。问题是，这一“不包括”，就除掉了大约 Array0% 的浏览器市场啊，在咱们抓狂之前，先来看看 ie 是什么处理 application/xhtml+xml 的：ie 不认得这种 mime type，它要么提示你是否下载那个文件，要么就把文件内容看成纯文本显示出来，反正是不可能正常显示标记。

　　这正是形成咱们不得不给 xhtml 文档标以 text/html 的缘由 1，实际上，目前 web 上 Array5% 的 xhtml，都是扮成 html 的 xhtml (包括 w3.org)，浏览器 (包括咱们引觉得傲的 mozilla) 压根没有用 xml 解析器去解析那些 xhtml，而是沿用处理标签汤的老办法。

　　这个时候你会问了，在我看起来，老办法显示得很好啊，干嘛为此感到头疼呢？问题正是出在“看起来”这个词上，实际上，一些细微可是不可忽略的差异仍然存在。

　　 用 application/xhtml+xml 方式解析 xhtml 与用 text/html 方式解析的差异

　　下面所说的“html”，就是指 text/html 的解析方式；相应地“xhtml”就是指“application/xhtml+xml”的解析方式。

1. 这是最重要的，严格的 xml 解析至少要求文档是 well-formed 的，也就是标签要正确开闭，& 等 xml 实体要正确使用。
2. 在 html 中 是用户所能看到的所有视域，给 body 设置背景色就是给整个文档设置了背景色，但在 xhtml 中并不是如此，给 设定背景色的效果和给 设定的不一样。
3. 在 html 中 css 规则中对元素的匹配是大小写不敏感的，body 和 body 匹配的是同一个元素，但在 xhtml 中倒是大小写敏感的。
4. 在注释中隐藏的 javascript 脚本会被 xhtml 忽略。
5. document.write() 不能在 xhtml 中使用。
6. html dom 和 xhtml dom 的元素和属性返回值是不一样的，html 中是大写，xhtml 中是小写。
7. 还有很多其余的 dom 问题。

　　总结起来就是，咱们正在普遍使用的实际上是一种看起来已经 xhtml 化的 html，想象一下吧，若是要求全部这些网站当即把 mime type 换成 application/xhtml+xml，即使用能够正常解析 xhtml 的浏览器来浏览，它们多数会死在前面列举的某一条缘由下，没法正常显示。然而这很差说是 xhtml 的错，正常的处理理应如此，只不过咱们一直被纵容了。

　　但是 w3c 仍是不断要求咱们以正确的 mime type 来提供 xhtml，为何呢？由于咱们要用到 xhtml 提供的好处啊，只有被认为是 xhtml 或者 xml 文档的东西，浏览器才会启用这些“好处”，好比你能够试着在 ie 中打开 xhtml 中嵌入的 mathml 看看，没有效果，它被看成 html 同样显示。

　　如今的问题是，既然把文档设定为真正的 xhtml 是如此的麻烦，会带来如此多的问题，干嘛不舒舒服服地呆在 html 上呢？为何要往 xhtml 过渡？xhtml 提供的“好处”值得咱们为此付出如此多的代价吗？

　　 xhtml 的优点

　　最重要的两点是：

1. 除了前面讨论的用户代理易于处理之外，实际上，大量的基于 xml 的工具，许多对 xml 有很好支持的编程语言，都可以方便地解析你的文档，从中提取出须要的信息。固然，也包括搜索引擎。
2. 你能够利用 xhtml 继承自 xml 的良好的扩展性，好比在 xhtml 中嵌入 rdf 数据，描述文档的语义信息；加入 mathml 标记，描述数学公式；加入 svg 标记，使用可伸缩矢量图型。

　　显然，若是文档连 well-formed 都作不到，优势 1 对你是无效的，就算有效吧，就我的来讲，其实也没有多少人对 xhtml 进行 xml 解析，由于能作到的，大概也就是从 h1、h2 这些标记中读出文档结构一类的功能，实在没什么大用处。

　　而第二点对大多数内容提供者来讲，太远了，rdf 是什么东东？加入 rdf 信息有什么好处？没多少人知道或者有兴趣知道；mathml？这是可扩展性目前用得最多的地方，由于不少 mathml 阅读和编辑工具已经普及了，但若是你不是个整天在公式中打转的科学工做者，多半对此也没有兴趣；svg 呢？却是挺有意思，但目前显然没有得到普遍的应用，事实上，往后可否得到普遍的应用，还要看它能不能在与 flash 的竞争中活下来：成为标准的东西被人抛弃也是常有的事。

　　总结起来，全部这些优势几乎都是一些空头支票，一些将来才能实现甚至将来都不知道能不能实现的东西，好比说你如今在开发一个 cms 系统，若是如今都已经不能保证里面的内容 well-formed，有什么理由说之后，数据愈来愈多之后，反而会回头去把错误的标记一一改正？

　　事实上，用不到这些空头支票，咱们的生活几乎没有受到任何影响。

　　那么，是否这就是说，xhtml 几乎就是一个鸡肋了 ？

　　 xhtml 啊 xhtml

　　行文至此，已经陷入了僵局，其实我本无心把 xhtml 说得那么差的，但问题是我每句说的都是实话呀，也没有忽略什么有必要提到的因素，但反复查考，总结起来仍是那一句话：xhtml 实际上是一个带一点理想主义的，对普通用户来讲，相比 html 4.01 并无显见优点的格式。

　　因而咱们就陷入了两难困境：刨掉那些花言巧语，没有任何显见的优势吸引咱们咱们转向 xhtml，但若是咱们永远躺在 html 4.01 舒服的被窝里，web 岂不是永不前进了？

　　答案仍是个问号。

　　 小结

　　原本，仅仅为了将来的锦绣图景，你们多数仍是愿意转向 xhtml 的，这大概是个博弈论中微妙的平衡，用户、浏览器厂家、标准制定者三家玩的一个游戏，但 ie 打破了这个平衡：它不支持 application/xhtml+xml，因而用户只好都以 text/html 来发布 xhtml 页面。

　　若是把他们人格化：我以为“用户”大概是个剃头挑子一头热的家伙，他们为本身的 xhtml 页面在一切浏览器上都如此美好而感到满意，却浑不知道背后其实仍是 html，本身没沾着一点“x”的好处。

　　这时标准制定者??他必定是个理想主义者??也不满意，由于用户其实仍是在以 html 的方式来写 xhtml 的，根本没准备好向 xhtml 进行转变的决心，标准制定者一心领着你们往 web 美好的将来远航，却发现不管是用户仍是浏览器厂商都在尽给他添乱。

　　浏览器厂商们??他们拥有最大的筹码，却始终冷眼旁观??此时却在开心地内斗，对此状况耸耸肩表示无能为力。

　　你可能会对此感到沮丧，但这的确是目前 web 中的事实，认可也好不认可也好，肯定一个目标，而后艰难而执著地前行，大概是咱们这些标准推广者惟一能作的。

　　 注释

1. 也并不是彻底没有办法，对于用 php 或者 asp 这样建立的动态内容而言，经过检测 http 头来进行内容协商是最好的办法：给 `accept: ` 中包含了 `application/xhtml+xml` 的请求提供 `content-type: application/xhtml+xml` 的数据，而给其余的请求提供 `text/html` 的数据。(在 456 berea street 的一篇文章详细解释了这种方法，实际上，打开 mozilla/firefox 的 `about:config` 页面，你能够找到相关的配置 `network.http.accept.default` 来验证一下 mozilla 是否发送了正确的 http 头。)，这几乎是一种完美的方法了 (实际上静态内容大概能够经过 web 服务器的内容协商功能实现这种提供方式)，但考虑到本文主要的目的是探讨是否应该用 xhtml，因此不在正文中详细讨论。
2. 仍旧是指对普通用户而言，事实上必须认可，xhtml 的出现对于整个 web 自己的长远发展绝对有好处。
3. 其实话不应说得那么绝，应该说 xhtml 的出现是绝对有必要的，但其带来的好处绝大部分是对 web 自己的，长远的，如今难以看出的好处，对用户或者开发者的好处微乎其微。