版本、兼容性以及標準

本文譯自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團隊處於不同的約束條件下，自然可自行作出他們自己的決策。