版本控制、兼容性和标准
在IEBlog和A List Apart上宣布的新的IE8版本切换开关，已成为网络上的热门话题。一些网络标准专家，如Eric Meyer和Jeffrey Zeldman，以积极的态度看待这个开关。另一些人，包括Dean Edwards、Robert O’Callahan和Anne van Kesteren，则认为这个提议是个坏主意。
我们在这个博客上很少谈论其他浏览器在做什么。虽然我们乐于在网络标准和测试上进行协作，有时也会有一些友好的竞争，但我们试图将重点放在打造我们能做到的最好的网络浏览器引擎上，而不是关注竞争。因此，我们不会对IE团队的决定进行深入评论。在兼容性和网络标准之间找到平衡是一项艰巨的任务，需要做出艰难的选择。
然而，有些人问到，包括 WebKit 在内的其他浏览器引擎是否会采用类似的版本切换。例如，最初的公告问道：“就我而言，我希望其他浏览器供应商能加入微软实现此功能。”我无法做出永久性的确定性声明，但目前看来，这种方法对我们而言不是一个好主意。你可能会问为什么？原因有以下几点。
WebKit 中的模式切换
WebKit 像大多数浏览器引擎一样，有一个由某些旧 HTML doctype 或 text/html 中缺少 doctype 声明触发的怪异模式 (quirks mode)。具有较新或未知 doctype 的文档，或以 XML 形式发送的文档，则在标准模式下处理。与 Mozilla 和 Opera 一样，我们在怪异模式下仅应用有限的非标准行为集，否则会在两种模式下修复错误，前提是这些错误对网络兼容性没有特定的重大影响。这与 IE 完全冻结怪异模式下旧行为的方法形成对比。
实际上，除此之外我们还有一些模式。少数几个 doctype 会触发所谓的“几乎标准模式”（almost standards mode），它是在标准模式基础上有一个小的偏差，主要影响图像在表格单元格中的布局；这模仿了 Mozilla。此外，对于以 XML MIME 类型提供的文档和以 HTML MIME 类型提供的文档，我们在渲染和 DOM 上也有一些差异，但我们正努力随着时间减少这些差异。最后，我们还有一个 Dashboard 兼容模式，它比怪异模式多了一些额外的怪异行为，以处理依赖于旧 WebKit 错误的 Dashboard 小部件。
可维护性
如你所见，这已经有不少模式了。模式过多会给维护引擎带来一些挑战。
首先，模式越多，全面测试引擎就越困难。我们在自动化测试方面采取积极策略，我们的布局测试常常能在发布甚至提交代码之前就发现关键问题。模式越多意味着许多事物需要在多种模式下进行测试。因此，这意味着更多的测试、开发者运行测试套件需要更多的时间，以及遗漏代码覆盖的可能性更高，尤其是在不同模式交互时。
其次，实现模式切换会损害代码的可黑客性（hackability）。可黑客性是我们的核心项目目标之一。这是新贡献者能快速上手的原因之一，也使我们能够快速开发新功能，同时提高性能、稳定性和安全性。
增加更多模式有两种可行的方式。一种是将所有引擎更改都以版本标志为条件。另一种是拥有整个第二套布局代码副本。无论哪种方式，都会成为开发者进入的巨大额外障碍，并使代码维护更加困难。
所以，总而言之，我们希望看到更少的模式，而不是更多。
移动设备就绪
除了可维护性，WebKit 引擎的一个重要特性是它易于部署在功能有限的设备上，例如手机。一些更突出的例子包括诺基亚的 S60 浏览器、苹果的 iPhone 和 iPod touch，以及谷歌的 Android 平台。这些和其他产品都包含功能齐全的 WebKit 版本，不打折扣。
然而，拥有更多的模式切换与此背道而驰。额外的代码（可能包括引擎的整个额外副本，至少也有一大堆额外的 if 语句）会对移动设备造成显著负担。这与我们保持精简高效的使命不太一致。
对标准和互操作性的承诺
我们认为增加更多模式切换对 WebKit 不是一个好主意的另一个关键原因是我们对网络标准的承诺，以及与其他浏览器的互操作性。我们坚信网络标准是实现互操作性的前进道路，我们与网络标准组织和其他浏览器供应商密切合作，以协调行为。
这种承诺的一部分是开箱即用地提供符合标准的行为。我们不要求你设置特殊偏好，或在你的网页中添加额外标记，或除了早已建立的标准模式切换之外的任何其他东西。这意味着 WebKit 能够真正通过基于标准的测试，例如 Acid2，以及未来即将推出的 Acid3，并且我们将随着时间推移，越来越像其他基于标准的浏览器。总的来说，网络开发者很高兴从我们的引擎获得自动的、不断进步的标准支持，事实上，我们对高级 CSS3 属性的支持已经在 iPhone 网络应用中掀起了一波创造力浪潮。
减少引擎碎片化
避免更多模式的另一个关键原因是减少网络内容作者必须处理的不同兼容性配置的数量。许多供应商发布基于 WebKit 的产品，我们非常依赖基于 WebKit 的浏览器 uptake 非常快的事实。许多网络开发者现在主要关注 Safari 3 而不是 Safari 2，因为在仅仅几个月内，大部分用户已经升级了。
但锁定兼容性意味着你需要更长时间地考虑旧版本浏览器的兼容性配置。而且没人想去考虑 Safari 2 中引擎的状态——我肯定不想！我们进行了数千次修复和改进，这些修复值得保留。
我们并不真正需要它
最后，虽然我们同情 IE 团队为实现高度标准兼容性所面临的艰难道路，但我们并没有真正遇到同样的问题。IE 团队提到 IE7 发布时收到了严重的负面反馈，原因在于网站预期大多数浏览器都能提供标准行为，但 IE 仍表现出 IE6 的错误。
但 WebKit 已经具有高度的标准兼容性。而且我们并不处于作为使用最广泛浏览器那种令人羡慕但又艰难的位置。我们为实现标准兼容性所做的修复很少会造成大范围的破坏，而且如果确实发生了，这往往是标准本身可能需要修订的迹象。我们不会收到网络内容作者关于他们的网站崩溃的投诉，相反，我们收到了许多对每个版本的引擎更好地处理网站的赞扬。
结论
所以，总而言之，我们认为没有太大必要在 Safari 中实现版本切换。我们认为维护引擎的多个版本对我们来说有很多缺点，好处很少。IE 团队当然面临不同的限制，可以自由做出他们自己的选择。