[译作]超越DOCTYPE: Web标准化,领先的兼容性,还有IE8

进步总是有代价的。在web浏览器方面,用户要承受开发者由于对开发工具的滥用和任何针对用户所使用的浏览器的假定而带来的代价(尤其是假定成了Internet Explorer, IE)。当那个被假定的浏览器发布了新的版本,修正了以前的bug,或者改变的某个特性的渲染方式(或者引进了新的特性)以及改变了某种行为,站点就会因此而崩溃,而我们的客户、经理和用户会感到很失望。

我们可以用几个小时的时间来解释为什么我们的站点崩溃了,但是并不比一开始就避免它崩溃来的好。

一些背景知识

基于带有在CSS支持上有重大改进的Internet Explorer 7发布的冲劲,IE开发组开始着手为IE8制作一个全新的渲染引擎——一个可以尽可能多地遵循CSS 2.1标准的引擎。他们努力工作的一个极致表现是正确地渲染了Acid2测试。对于那些关注者来说,这意味着IE在不久的将来将生成出内容和数据URL,永久地放弃hasLayout,这一点已经得到确认。这一点将会使得它的渲染与同样通过Acid2测试的其他浏览器,如Safari, iCab, Konqueror和Opera,到同一起跑线上。(Firefox 3同样也通过了Acid2,但到撰写此文时并未发布。)

在开发新的渲染引擎过程中,IE开发组对IE 7的反馈很重视。一些标准的狂热者甚至一些微软fans都认为,在IE 7中对bug的修正和对CSS的支持增强方面,开发组做的并不够。但是数量更多的开发者则抱怨,他们原本看起来很好的网站,却在IE 7中不能正确渲染。在他的博客中,标准拥护者Roger Johanssen提出了三个导致错误的原因,鉴于他们对于支持标准的迫切要求,IE开发组发现了第四个原因:DOCTYPE开关,一个开启现代CSS布局核心的技术,因为保证兼容性的缘故,存在着致命地瑕疵。

DOCTYPE开关是坏的

早在1988年,Todd Fahrner就发明了一种能够使浏览器使用两套渲染模式的技巧:一种按照开发者的要求遵循标准,另一种则是为其他人准备的。这个概念非常简洁。当一个客户端遇到一个包含完整遵循了当前HTML标准(例如,HTML 2.0不会省略它)的DOCTYPE声明的文档时,它将假定作者知道她自己在做什么,然后使用遵循标准模式来渲染页面(布局元素使用W3C提倡的盒模型)。但是如果不包含DOCTYPE或者包含了一个不标准的DOCTYPE时,文档将会按照一种“奇异”模式进行渲染,例如,布局元素使用IE 5.x/Windows下的非标准的盒模型进行渲染。

这个概念于两年后首次应用于IE5/MAC平台上,并很快被其它浏览器制造商采用。追随标准的开发者们为了使网页通过标准验证,早已经将一个DOCTYPE包含在他们的网页中,因此浏览器根据这个特性来渲染页面,不会造成多余的代价。那些没有明确的标准化概念的开发者则发现,他们写的页面被浏览器特殊对待,因为他们自己以及他们使用的开发工具,都没能够插入正确的DOCTYPE

不幸的是,两个关键性因素,共同导致了DOCTYPE成为了判断标准的标准:

  1. 由于A List Apart和The Web Standards Project的鼓励,由远见的开发者和开发工具开始在他们编写和生成的标记语言中插入合法、完整的DOCTYPE
  2. IE6的渲染行为已经有五年没有改变,导致很多开发者以为它的渲染行为是正确的,而且不太可能变化。

两个原因合起来共同导致了DOCTYPE被破坏,因为它有一个致命的缺点,它认为当你使用了DOCTYPE的时候,就意味着当它向标准靠拢的时候,你要为你自己的行为负责,因为你知道你自己是在做什么,并且希望渲染效果越精确越好。我们怎么知道渲染会失效?当IE7推出的时候,站点就惨不忍睹了。

当然,如Roger指出的那样,崩溃的站点中是因为它们使用了IE6特定的CSS技巧(hacks)。但是更多的灾难是由于它们的开发者仅仅在IE6中检查网站的效果——或者仅仅想关注一下站点在IE6下看起来是什么样子的,因为他们仅仅在一个具备相同浏览器的环境中部署站点(比如,企业的内部局域网内)。当然,你可以耸耸肩,说既然IE6的渲染错误是已经被很好地整理过的,这些开发者可以更了解这些错误,但是,这样的话,你就忽略了其实很多开发者根本不曾明确地选择“标准模式”这个事实,或者根本就不知道有这么个模式的存在。

Chris Wilson,Internet Explorer的平台架构师,经常提到说,IE开发过程中的一条核心原则是,IE开发组做出的任何一个决定,不能“破坏现有网站”。遗憾的是,IE7恰恰破坏了相当一部分开发者的网站。为了避免同样的错误再次发生,Microsoft向The Web Standards Project(我是其会员之一)和几个其他的追求标准的开发者求助,请他们提供一个更好的方法,能够允许开发者“适应到”符合标准的开发上来。这个目标就是寻求一种方法,能够比DOCTYPE更清楚,并且能够被所有浏览器所实现,而不仅仅是IE。

美好的未来

在去年的SXSW上,我非常有幸地看到New York Public Library’s Carrie Bickner制(她正好是ALA的作者的妻子,Jeffrey Zeldman)作的一个绝好的发光二极管标语,标语写,“保护我们的数字遗产和私人收藏”,探讨的是当图书馆和私人当试图保留电子存档时遇到的问题。大部分的问题是文件格式和应用程序的问题:例如,Microsoft Office 2007,不能可靠地渲染一个Word 1.0文档,而大部分人一开始就认为它应该能够正常显示。这个标语引我深思,网络在创作力的推动下是如何改变的,以及网络在标准推行的过程中,将会如何继续这个变化。

作为一个web标准的支持者,我希望看到浏览器在不停地加进新的特性的同时,能够继续增强对标准的实现,但是同时我认为,浏览器应该保护那些我们已经花了这么多努力——基于表格的布局等,做成的网站。当然,很多从“时间机器”里出来的因为DOCTYPE对它们的良好保护,不会出现错误,但是,如果一个网站是基于IE6所谓的“标准”模型建设的呢?我们已经看到,很多这种情况,IE7是不会正确地渲染它们的。这是不是意味着我们要保留一个IE6,以便当我们不能按照作者意图浏览这些网站的时候用?这恰恰是很多图书馆为了能够浏览老的文件所做的事情。IE8即将诞生,我们面对着同样的潜在问题,就是那些按照IE7渲染引擎编写的文档。如何解决?

原文:Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8,Aaron Gustafson

发表评论