进步总是要有代价的。 对网页浏览器来说， 由于开发者像是宣传真理一样的拍着胸部担保着一些编辑器和浏览器(特别是Internet Explorer)， 用户们为此花费很多的成本。 而当这个浏览器推出了一个新版本， 然后又修正了之前版本的一些错误和对规范的误解(或是引入了新的)， 或是以任何方式改变行为时。 站点突然崩溃了， 然后我们的客户， 我们的老板和用户们都感觉到非常的不开心。

　　我们也许可以花上一段时间来解释为什么我们的网站坏了， 但是如果他们没有被破坏那不是更好吗？

一点点背景介绍
　　在成功的放出了更好的支持CSS的Internet Explorer 7的动力下， IE团队开始在一个崭新的渲染引擎(更好的遵照CSS 2。1规范)上开始进行IE 8的开发工作。 在他们的努力下， 浏览器已经可以相当精确地表现出 "Acid2 test" (http：//webstandards。org/action/acid2/) 。 这些你跟进的消息， 意味着IE将很快的支持生成内容和数据的URLs， 而且经确认， hasLayout会被永远取消。 它的表现结果会让其他通过Acid2测试的浏览器们进行投票(包括： Safari， iCab， Konqueror， and Opera。 Firefox3也已经通过了Acid2测试，但是在文章编写的时候还没有放出。)

　　在新引擎的开发过程中， IE团队谨记IE 7放出后的反面评价。 一些web标准的狂热者甚至是一部分微软的崇拜者感觉到在"IE7中他们做得还不够 (程序缺陷的修正和CSS支持的改进上)"。  但是有很大的一群开发者在感到疑惑， 因为他们的网站在IE6中表现的很完美， 但是到了IE7就完全崩溃了。 web标准倡导者 Roger Johanssen 在他的博客中提出了 "页面被破坏的三大原因" (http：//www。456bereastreet。com/archive/200611/three_reasons_sites_break_in_internet_explorer_7/)， 这些都驱使大家去改善对标准的支持。 IE开发团队发现了第四点： 文档类型转换(DOCTYPE switch)， 一个启用现代CSS布局的核心技术在标志兼容性上有致命的缺陷。

文档类型转换器失效了
　　回到1998年， Todd Fahrner 的 "came up with a toggle(http：//web。archive。org/web/20030212115103/http：//www。geocrawler。com/archives/list-name。mbox/123/1998/7/0/1037920/)" 方法能允许一个浏览器提供两套渲染模式： 一是给期许遵守标准的开发者的， 另一个是给其他所有人的。 这个观点精辟简单。 当用户端代理遇到对当前HTML标准的Doctype声明良好定义的文档时(也就是 HTML2 不会取消它)， 创作者就会知道她在做什么， 并且用"标准"模式渲染这个页面(用W3C的盒模型元素布局)。 但是在没有Doctype或者定义了不正确Doctype时， 文档会被用"Quirks" 模式渲染， 也就是说， 用windows版的IE5。X的非标准盒模型进行元素布局。

　　这个概念在两年后的Mac版的IE上被首次运用， 这种方法很快的被其他浏览器制造者采用， 意识到标准的开发者会在他们的文档中包含正确的Doctype， 这样做他们的部分在浏览器根据规范进行渲染时就不需要额外的工作了。 不注意标准的开发者很幸福的， 他们自己没有发现， 他们以及他们的工具都没有为他们插入正确的Doctype， 但是他们的文档在浏览器中被特殊对待了。

　　不幸的是， 因为两个关键问题， 为配合广大的呼声，Doctype不可能持续充当标准模式的转换器了：

A List Apart和Web标准项目的推广， 善良的编辑器开发者开始为他们的工具生成的标记中插入有效的，完整的Doctype。
　　IE6的渲染行为有5年没有更新了， 这让大部分开发者认为这个引擎是正确的， 并且不太会发生改变了。
这两种情况破坏了Doctype的转换， 因为它有致命的缺陷： 使用有效的Doctype意味着你明白你在通过web标准做什么， 你希望获得更正确的渲染， 但是我们怎么知道它失败了呢？ 当IE 7降临的时候， 网站们变样了。

当然， 就像Roger指出的那样， 一些被破坏的网站是使用IE6特有的CSS Hack(通常不会有提供选择的机会)。 但是发生这样的惨剧是因为他们的开发者只在IE6当中测试他们的页面， 或者他们只关心在IE6中， 他们的网站是什么样的。 因为他们为使用同一类浏览器的族群开发网站(比如说公司的内部网)。 现在当然， 你可以只是耸耸肩然后说， 这是被证明是IE6的错， 但是这些开发者应该知道的更多， 但是你会忽略一个事实， 就是这些开发者们从来没有明确的选择 "standards mode"， 甚至他们知道有这么个模式存在。

　　Chris Wilson， Internet Explorer的平面架构师， 经常提到的一个在IE上开发的核心原则： IE团队做出的任何选择的目的绝对不是 "破坏网页"。 可悲的是， IE 7却让去多人面对这个事实。 Microsoft不愿意造成第二次错误， MicroSoft开始进入Web标准项目(我是其中成员之一)， 以及其他几个有标准意识的开发者， 向我们寻求帮助去寻找一个允许开发者自主选择支持web标准的好办法。 最终的目标是找到一种可以比Doctype选择器更直接清楚的方法， 可以运用到任何浏览器中， 不只是IE。

美好的未来
　　在去年召开的SXSW中， 我有幸看到了纽约公共图书馆的Carrie Bickner(同时是ALA的出版者Jeffrey Zeldman的妻子)领导的神奇的议题。 "保存我们的数字遗产以及我们的个人收藏"， 讨论图书馆和个人在维护数字档案时遇到的问题。 大部分的问题源自文件格式和应用程序的进步： 例如 Microsoft Office 2007， 它不能可靠的展现一个本来可以展现的word 1。0的文档。 这个议题让我想到了网页从建立开始会有怎样的改变， 以及它们在web标准进步的同时又会怎样的改变。

　　作为一个web标准的支持者， 我想看到的是浏览器在提供新的支持的时候不断的为执行标准化而改进。 同时我也看到了保护我们曾经辛辛苦苦建立的基于table布局的网站的重要性。 当然， 大部分通过 " Wayback Machine " 存在的错误因为Doctype转换器仍然可以很好的为他们服务而暂时没有遭受到打击， 但是那些让IE 6执行"standards"模式的网站呢？ 我也都知道， 在很多案例下， IE 7 也不能完全的渲染它们。 这是不是意味着我们有必要保留一份IE 6的备份在手边， 为了浏览这个网页达到的效果如同创作者想要的那样？ 这就是很多图书馆为了浏览古老的文件所做的事情。 在IE 8的时代， 我们同样会面对这些潜在的问题， 用IE 7的渲染引擎生成的正常的文档会不会在IE 8中变了形， 怎么来解决这个问题呢？

针对浏览器版本
　　在理想的世界里， 当然， 所有的规范都将是完美的， 而且他们在用户端将直接的完美的被执行。 在更实际的理想世界里， 浏览器厂商应该为新用户直接提供符合标准的更新， 用户可以不费吹灰之力的使用这些最新版本的浏览器。 如果是这样， 我们这些开发者就可以用最新的最伟大的技术去构建网站和应用程序， 而不用考虑向下兼容的问题。 但是我们都知道， 现实世界离这个状态还差不太远。

　　标准总是在断断续续的开发和改进， 有时会花上几年时间， 提出他们认为的"推荐"状态。 但是浏览器发行的周期是被产品管理和市场的关注(安全性， 功能， 速度)左右的， 很少有能和标准规范的定稿相符合的， 甚至当浏览器开发商他们自己很积极的用非常标准的方法进行开发， 但是用户们， 特别是同样组织背景的用户， 往往是很懒于更新他们的浏览器的。

　　我们面对所有这些因素， 网站开发者们在制作网站时都会有点不是滋味， 我们怎么确保让浏览器渲染的结果继续保持我们想要让他们呈现的样子？

　　我们可以指定我们想要用的语言的版本， 就像是 CSS 2。1或者JavaScript 1。5。 但是不幸的是， 浏览器渲染通常只会执行规范的一部分， 而且在浏览器之间对规范的解释也会存在差异。 所以任何两个不同时代的浏览器会对CSS有完全不同的渲染， 或者对一个同一个表单控制器触发不同的事件。

　　因为这些捣乱在工作中出现， 我们真得只剩下一种选择， 让我们今天创建的网站在未来五年中看起来就像今天一样： 定义一个这个网站建立并测试过的浏览器版本列表， 然后要求浏览器制造商用一种方法执行原先的渲染和脚本解释引擎来让这个网站看上去和建立的时候一样， 在未来有较好的表现。

　　这就是为什么我们团队决定推荐IE8， 然后我们也希望在其他浏览器中也能很好的执行。

保持语法的简炼
　　确保浏览器的"版本目标" 能较容易地被开发者接受的一个关键是能够用手动或是编辑器简单的执行。 我们考虑了很多语法方案， 包括 条件注释型语法， 按XML Porlog方式的处理指令， 又或是HTML档案， 比如那些被微格式区域所采用的， 但是几乎都没有Meta元素来的更适合这个工作。

　　用一个简单的Meta声明， 我们能指定在IE8中的渲染引擎来使用， 例如， 插入这样一段代码

 　　<meta http-equiv="X-UA-Compatible" content="IE=8" />

　　在文档的head区域里， 可以让IE 8渲染用最新的标准模式渲染这个页面， 这个语法可以很容易的扩展到其他浏览器上：

 　　<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

　　为了加快处理这个固定指令的速度， 我们要像处理字符编码信息meta时运用的优先级机制引入到这个版本目标meta元素上， 为了让它起到作用， meta元素必须放到文档的head里， 并且尽可能的靠近顶部。 它可以让其他的meta元素或title元素更优先，  但是一定要在其他的元素的上面， 并且不同通过JavaScript把它加进DOM中。

　　大家注意到， 我们在这里用到的meta元素是HTTP-equivalent类型的， 这就意味着我们可以用下面这种方法设置服务器的头文件来获得同样的效果。

 　　X-UA-Compatible:IE=8;FF=3;OtherUA=4

　　我们也能同时使用两种方法， 例如我们可能通过使用头文件的方法设置一条基线来全局定义一整个网站， 然后用meta的方法在单个的页面覆盖头文件的设置。

逐步加强(progressive enhancement)哪去了？
　　使用了这个能把你的网站为某个浏览器版本进行锁定是相当神奇的， 这样你的网站在将来也表现出不错的可用性， 但是这样做会不会破坏了逐步加强的概念了呢？ 是不是我们都要改变我们建站的方法了呢？ 我们能不能继续自动应用新的CSS属性， 它们会变得可用吗？ 这是当我们还是讨论"版本目标"的可行性时我的许多疑问中的几个。

　　例如， 让我们假设 IE 8不再继续支持生成内容(generated content) - 如果Acid2公布任何迹象的话， 它会， 请容忍我把它作为一个例子： 我们在"锁定了" IE 8 的网站上使用生成内容的话， 另外除了IE之外的现代浏览器会渲染生成内容， 但是就算是IE 9又支持了生成内容， 有人用IE 9访问这个网站的话， 还是会看不到生成内容， 因为这个网站被锁定在 IE 8 了。 如果把这个网站的锁定升级到IE 9， 那么生成内容就显示出来了， 这是和逐步加强相违背的。

　　失去了逐步加强这个特点着实让我头痛， 但是这种行为是会发生的最好的事情了， 尤其是当网站是面向大众的。 毕竟， 我们不应该去假设浏览器在将来会是什么样。 如果 IE 9 的一个更改破坏了我们网站的布局或是我们的script中的一个功能的话， 这可能对于我们的用户来说会灾难性的， 并且会给我们的团队带来疯狂的混乱 - 在新浏览器下修复这个网站的功能(我们已经上了太多条船了)。 针对版本给我们团队一种决定什么时候支持新浏览器的能力， 更重要的是， 给我们足够的时间作出必要的调整来支持新浏览器。

　　针对版本意味着逐步加强的终结吗？ 在这个问题上， 不是。 首先， 我们仍然在未来的几年内会处理遗留 / 预先锁定浏览器， 并逐步加强， 这是个行之有效的方法将在他们中间逐步支持不同阶段的CSS和JavaScript。 此外， 还有一个地方提供IE浏览器的样式和脚本的补丁， 虽然我们希望随着时间的过去这样的需求会越来越少。 最后， 用逐步加强技术撰写JavaScript仍旧会很大程度上减少为了准备支持新浏览器而作出的重构时间。

技巧延伸： 生活在"边缘"
　　对于那些乐意抛弃严谨的态度的， 不计后果的， 或者其他不计后果的放任的口语化编程习惯， IE 会支持一个关键词： "edge："

 　　<meta http-equiv="X-UA-Compatible" content="IE=edge" />

　　这个选项， 虽然我们极力阻止， 但是这会让一个网站把版本锁定在所发布的最新的IE浏览器上。 这比设定一个不切实际的 IE=1000要来的清晰一点， 是吧？ 但是从版本目标的所有优点来说， "edge"值除了实验性的网站外都是不切实际的吧。 那是因为就算是 Eric Meyer也没办法预料在新版本浏览器中会有什么布局或是脚本的缺陷。

对未来的希望
　　多年来， 我们设计师和开发者都渴望着有种方法可以让我们的网站更可靠。 除了为撰写跨平台的样式和脚本而头痛， 我们还必须处理一些由于新浏览器的发布而造成的一些不可预料的损坏。 向客户， 老板和用户解释这个不可预期的损坏从来不是个开心的差事。 但是， 通过IE 8的版本目标的介绍， 让隧道的尽头出现了一点光亮。 我， 作为其中一个， 希望其他的浏览器渲染都一起参加Microsoft来贯彻这个方法。