原文： http://www.alistapart.com/articles/beyonddoctype

作者：Aaron Gustafson

 译者：zhaozy in 3user.com

转载请注明作者和译者信息,谢谢!

进步总是要有代价的. 对网页浏览器来说, 由于开发者像是宣传真理一样的拍着胸部担保着一些编辑器和浏览器(特别是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不可能持续充当标准模式的转换器了:

1. A List Apart和Web标准项目的推广, 善良的编辑器开发者开始为他们的工具生成的标记中插入无效的,完整的Doctype.
2. 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中变了形, 怎样来处理这个问题呢?