版本、兼容性以及标准

本文译自Maciej Stachowiak在webkit团队blog上的文章Versioning, Compatibility and Standards。本文可作为分歧巨大的“HTML的版本问题”的背景材料，对此问题的探讨也请移驾此处讨论。注意，【】中的内容为我所加的注。

Versioning, Compatibility and Standards

版本、兼容性以及标准

Posted by Maciej Stachowiak on Tuesday, January 22nd, 2008 at 11:51 pm
Maciej Stachowiak发表于2008年1月22日星期二

The new IE8 version targeting switch, announced on IEBlog and A List Apart, has been the talk of the web. Some web standards experts, like Eric Meyer and Jeffrey Zeldman see the switch in a positive light. Others, including Dean Edwards, Robert O’Callahan and Anne van Kesteren think the proposal is a bad idea.
IEBlog和 A List Apart上声明了新的IE8的版本目标切换特性（version targeting switch），这成为了最近谈论的焦点。一些web标准专家，如 Eric Meyer和 Jeffrey Zeldman对这种切换特性给予了正面评价，而其他人，包括 Dean Edwards、 Robert O'Callahan和 Anne van Kesteren，则认为这一提案是个糟糕的主意。

We don’t talk much about what other browsers are doing on this blog. While we’re happy to collaborate on web standards and testing, and sometimes share a little friendly rivalry, we try to keep our focus on making the best Web browser engine we can, not on the competition. So we’re not going to give in-depth commentary on the IE team’s decision. Straddling compatibility and Web standards is a tough job requiring tough choices.
在本blog【webkit的官方blog】上我们不会去讨论其他浏览器的所作所为。尽管我们很高兴在Web标准和测试方面进行合作，有时还参 与一点友好的竞争，但我们希望把关注点集中于如何尽我所能创造最好的Web浏览器引擎，而不是竞赛上。所以我们不会对IE团队的决定多嘴多舌。平衡兼容性 和Web标准总是一项艰难的工作，需要做出艰难的选择。

However, some have asked if other browser engines, including WebKit, would adopt a similar version switch. For example, the original announcement asks, “I, for one, hope other browser vendors join Microsoft in implementing this functionality.” I can’t make any definitive statement for all time, but such an approach does not seem like a good idea to us currently. Why, you may ask? There are a few reasons.
然而，有人问其他浏览器引擎，包括WebKit，是否能引入类似的版本切换机制。比如，最初声明中提到，“我本人，希望其它浏览器厂商也能和微软一起，实现该特性。”我并不能做出权威声明，但是可以说，这一想法对我们目前来说并不是一个好主意。

Mode Switches in WebKit
WebKit中的模式切换

WebKit, like most browser engines, has a quirks mode that is triggered by certain old HTML doctypes, or lack of a doctype declaration in text/html. Documents with newer or unknown doctypes, or sent as XML, are processed in standards mode. Like Mozilla and Opera, we apply only a limited set of nonstandard behaviors in quirks mode, and otherwise fix bugs across both modes, if they do not have a specific significant impact on Web compatibility. This is in contrast to the IE approach of completely freezing old behavior in quirks mode.
WebKit，正如大多数浏览器引擎一样，具有 怪癖模式， 可由特定的老的HTML doctype或者在text/html下不写doctype声明来触发。文档如果使用新的或者未知的doctype，或者作为XML传送，则会按标准模 式处理。像Mozilla和Opera一样，我们在怪癖模式下引入的非标准的行为是相当有限的；其他那些bug，如果对于Web兼容性没有特别重大的影 响，则在所有模式下都会被修复。这与IE的方式截然相反，IE的方式是在怪癖模式中完全沿袭旧的行为。

We actually have a few modes besides that. A handful of doctypes trigger what is called “almost standards mode”, which is standards mode with one minor deviation, mainly affecting how images lay out in table cells; this is copied from Mozilla. In addition, we have a few rendering and DOM differences between documents served with an XML MIME type and those served with an HTML MIME type, but we are trying to reduce these over time. And finally, we have a Dashboard compatibility mode that has a few extra quirks beyond quirks mode, to handle Dashboard widgets that were coded to depend on old WebKit bugs.
我们其实还有一些其他的模式。有一些doctype会触发所谓“几乎标准模式”，也就是标准模式附带一个小例外，主要是影响图像在表格单元中的 布局方式【即在单元格中的图像会紧贴边界，而不会因默认的baseline对齐方式留下空白】；这一方式是从Mozilla照搬来的。此外，文档按照 XML MIME类型传输或HTML MIME类型传输，在呈现效果和DOM模型上还有少许不同之处，但是我们试图逐渐消除这些不同。最后，我们还有一个Dashboard兼容模式，它在怪癖 模式之外还有一些额外的怪癖，以满足一些Dashboard微件（widget）的需求，它们的代码依赖某些旧的WebKit的bug。

Maintainability
可维护性

As you can see, this is quite a few modes already. Having lots of modes raises a number of challenges for maintaining the engine.
如你所见，我们已经有好些不同的模式了。这对于引擎的维护来说是很大的挑战。

First, the more different modes there are, the harder it is to fully test the engine. We have an aggressive approach to automated testing, and our layout tests often find critical problems before they are shipped or even checked in. Having more modes means many things need to be tested in multiple modes. So that’s more tests, more time for developers to run the test suite, and more chances of missing code coverage, especially when different modes interact.
首先，模式越多，越难以对引擎进行全面测试。我们采用积极的 自动测试方 式，通过我们的布局测试，那些严重的问题一般总能在正式发布甚至签入代码库之前就被发现。更多的模式意味着有许多事情需要在多个模式中进行测试。也就是要 写更多的测试，开发者要花更多的时间来运行测试套件，并且更有可能达不到代码的测试覆盖度，特别是当不同模式相互作用时。

Second, implementing mode switches hurts hackability of the code. Hackability is one of our core project goals. It’s part of the reason new contributors can dive in quickly, and enables us to rapidly develop new features, while improving performance, stability, and security.
其次，实现模式切换会损害代码的hackability。hackability是我们这个 项目的核心目标之一。新的贡献者之所以能快速切入，hackability是很重要的一点，它让我们在改进性能、稳定性和安全的同时，也能快速开发新的特性。

There’s two plausible ways to add more modes. One is to make all engine changes conditional on a version flag. Another is to have a whole second copy of the layout code. Either would be a huge additional barrier to entry for developers, and would make it harder to maintain the code.
要增加新的模式，有两种看似可行的方式。一种是引擎所有的改动都加上对版本号的条件判断。另一种则是完整拷贝一份布局代码。无论哪种方式，对于开发者的参与来说都是一个巨大的额外障碍，也使得代码更难维护。

So, bottom line, we’d like to see fewer modes, not more.
所以基本上，我们希望模式更少，而不是更多。

Mobile-Readiness
移动适用性

In addition to maintainability, an important feature of the WebKit engine is the ease with which it is deployed on limited-capability devices such as mobile phones. Some of the more prominent examples include Nokia’s S60 Browser, Apple’s iPhone and iPod touch, and Google’s Android platform. These and other products all include a full-powered version of WebKit, no compromises.
除了可维护性之外，WebKit引擎的一个重要特色是易于部署到功能有限的设备，如移动电话上。大家熟知的例子包括诺基亚的 S60浏览器、苹果的 iPhone和 iPod touch，以及谷歌的 Android平台。这些产品都包含了一个WebKit的全功能版本，没有损失任何功能。

However, having more mode switches cuts against this. The extra code (possibly whole extra copies of the engine, at the very least a whole lot of extra if statements) would be a significant burden on mobile devices. It’s not very well aligned with our mission of staying lean and mean.
然而，如果有更多的模式切换，则会损害这一点。额外的代码（可能是所有额外的引擎拷贝，或者至少是大量额外的if语句）对于移动设备来说会是严重的负担。这与我们至精至简（lean and mean）的目标不相一致。
 
Commitment to Standards and Interoperability
对于标准和互操作性的承诺

Yet another reason we feel more mode switches are not a good idea for WebKit is our commitment to Web standards, and to interoperability with other browsers. We strongly believe that Web standards are the path forward for interoperability, and we work closely with Web standards groups and other browser vendors to align behavior.
我们认为对于WebKit来说更多模式切换不是好主意，还有另一个原因，那就是我们对于Web标准的信仰，以及我们对于与其他浏览器的互操作性 的承诺。我们坚定的相信，Web标准是通向互操作性之路，并且我们与Web标准团体和其他浏览器厂商紧密合作，以统一浏览器的行为。

Part of this commitment is delivering standards-compliant behavior out of the box. We don’t ask you to set a special preference, or to add extra markup to your web page, or anything else beyond the long established standards mode switch. That means WebKit can truly pass standards-based tests like Acid2 and someday the forthcoming Acid3, and we’ll work more like other standards-based browsers over time. In general, web developers are happy to get automatic ever-advancing standards support from our engine, and indeed our support for advanced CSS3 properties has unleashed a wave of creativity in iPhone web apps.
让遵循标准的行为即时可用，也是这一承诺的应有之义。我们不会要求你设置特别选项，或是在你的网页中加入额外标记，除了已经存在的标准和怪癖模式切换之外，我们不会要求你做任何其他额外的事情。这意味着WebKit能真正的通过基于标准的测试，如 Acid2和未来的Acid3，我们也会与其他基于标准的浏览器逐步趋向一致。总的来说，web开发者乐于从我们的引擎获得自动不断提升的标准支持，事实上我们对于高级CSS3特性的支持已经在iPhone的web应用中释放了 巨大的创造力。

Reducing Engine Fragmentation
减少引擎的散乱

Another key reason to avoid more modes is to reduce the number of different compatibility profiles that web content authors have to deal with. With many different vendors shipping WebKit-based products, we rely a lot on the fact that uptake of WebKit-based browsers is really fast. Already many web developers are focusing primarily on Safari 3 and not Safari 2, because in only a few months the majority of users have upgraded.
应避免更多模式的另一个关键原因，是为了减少web内容创作者所需面对的不同兼容性配置方案（profile）的数量。随着许多不同的厂商采用 基于WebKit的产品，市场对于基于WebKit的浏览器接受很快。已经有许多web开发者主要为Safari 3而不是Safari 2做开发，因为在很短时间内大多数用户就已经升级。

But locking in compatibility would mean you have to think about the compatibility profiles of old browsers a lot longer. And no one wants to think about the state of the engine in Safari 2 - I sure don’t! We made thousands of fixes and improvements and those fixes deserve to stick.
而兼容性锁定意味着你必须更长久的考虑旧浏览器的兼容性配置方案。没有人想去考虑Safari 2中引擎的版本状况——至少我不想。我们已经做了数以千计的修补与改进，它们可不好对付【这句意思吃不准】。

We Don’t Really Need It
我们并不很需要它

Finally, while we sympathize with the tough road that the IE team has to travel to achieve a high degree of standards compliance, we haven’t really experienced the same problem. The IE team has mentioned severe negative feedback on the IE7 release, due to sites expecting standards behavior from most browsers, but IE6 bugs from IE.

最后，我们理解IE团队为了做到高度遵循标准，需要经历艰难之旅，不过我们自己并没有这样的问题。IE团队提到了IE7发布后严重的负面反馈，这是因为对于大多数浏览器，网站期待的是符合标准的行为，唯独对于IE，网站期待的是IE6的bug。

But WebKit already has a high degree of standards compliance. And we are not in the enviable but tough position of being the most widely used browser. The fixes we do for standards compliance rarely cause widespread destruction, and when they do, it’s often a sign that the standards themselves may need revision. We do not get complaints from web content authors about their sites breaking, on the contrary we get a lot of praise for each version of the engine handling web sites better.
WebKit已经高度遵循标准了。我们也没有像最广为使用的浏览器那样，处于令人羡慕却又进退两难的位置。我们为遵循标准而做的修改极少会造成 广泛的破坏，而且如果产生破坏，那往往说明标准本身需要修订。我们没有从web内容创作者那儿听到网站坏掉的抱怨，相反，我们得到了大量的赞扬，称赞我们 每个引擎版本都能使网站变得越来越好。

Conclusion
结论

So, in conclusion, we don’t see a great need to implement version targeting in Safari. We think maintaining multiple versions of the engine would have many downsides for us and little upside. The IE team is, of course, under different constraints and free to make their own choices.
所以，结论是，我们并没有发现有必要在Safari中实现版本目标（version targeting）。我们认为维护引擎的多个版本对我们来说是弊大于利。当然，IE团队处于不同的约束条件下，自然可自行作出他们自己的决策。