翻译 2008年02月11日 15:00:00

本文译自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.
IEBlogA List Apart上声明了新的IE8的版本目标切换特性(version targeting switch),这成为了最近谈论的焦点。一些web标准专家,如Eric MeyerJeffrey Zeldman对这种切换特性给予了正面评价,而其他人,包括Dean EdwardsRobert O'CallahanAnne 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.

Mode Switches in 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。


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.

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.


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浏览器、苹果的iPhoneiPod 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.

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.


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内容创作者那儿听到网站坏掉的抱怨,相反,我们得到了大量的赞扬,称赞我们 每个引擎版本都能使网站变得越来越好。


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团队处于不同的约束条件下,自然可自行作出他们自己的决策。

谈谈Linux应用程序 ABI兼容性

  • linyt
  • linyt
  • 2015年07月11日 16:56
  • 5062


很多时候,我们在开发的过程中会被要求兼容IE8,那为什么最多的会是IE8呢?说一个事实,XP中IE能升级的最高版本就是IE8···恩,别的就不说了,入正题 关于浏览器的兼容性,不同的浏览器对不同元素...
  • shya_
  • shya_
  • 2017年02月17日 15:20
  • 1112


2015-12-03 kelly blacker 说明:以下内容整理自InfoQ的专访,blacker加了一些注释。 问题1: InfoQ:JavaScr...
  • dj0379
  • dj0379
  • 2016年07月30日 00:32
  • 930

App Store 版本兼容性显示问题

app上传到App Store后显示下图的兼容性 可以通过下面方法将兼容性修改为简单的: build settings 里面的Build Active Architecture Only re...
  • iOS_yanmy
  • iOS_yanmy
  • 2017年09月20日 14:24
  • 358


  • samshmily
  • samshmily
  • 2011年05月10日 22:41
  • 690


  • Galdys
  • Galdys
  • 2012年12月14日 11:06
  • 2056


一、web标准web标准 web标准简单来说可以分为结构、表现和行为: 其中结构主要是有HTML标签组成。或许通俗点说,在页面body里面我们写入的标签都是为了页面的结构。 表现即指css样式表...
  • u012698342
  • u012698342
  • 2017年04月05日 16:37
  • 319


  • web_note
  • web_note
  • 2017年06月21日 10:51
  • 3453

java 对象序列化和对象反序列化操作时的版本兼容性问题

结合书和网上一些资料,现总结如下: serialVersionUID作用: 序列化时为了保持版本的兼容性,即在版本升级时反序列化仍保持对象的唯一性。 有两种生成方式: 一个是默...
  • u014396915
  • u014396915
  • 2015年07月28日 09:26
  • 1033


用过jQuery的朋友都知道jQuery不同版本会引发冲突,本文就此问题提出有效的解决方案如下: 案例:解决jQuery1.3.2和1.4.2的冲突。(本例已测试通过!) 第一步:在1.4...
  • liwenjieIT
  • liwenjieIT
  • 2017年09月06日 15:33
  • 773