这个概念在两年后的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中变了形, 怎么来解决这个问题呢?
