下图是2D graphics 在不同port中的依赖关系，几乎是各自使用了完全不同的库来实现绘制操作:

　　举一个更细节的例子，一个刚被引入的特性CSS.supports()只有win和wincairo两个移植版本没有支持,因为它们并没有启用css3特性。

　　简单地说共享的组件就是WebCore。它其实就是通常意义上大家所说的WebKit，一个排版、渲染引擎，同时是HTML和SVG解析库。而WebKit是WebCore与ports之间的绑定层(bindinglayer)，平时的交流并不太在意它。

　　如下图所示：

　　WebKit中的许多元件是可以替换的 (上图中的灰色部分)。

　　比如WebKit的默认JavaScript引擎JSC(JavaScriptCore,当由KHTML开始创建WebKit的同时基于KDE的KJS实现而来),在Chromium port由V8替换，并用独特的DOM bindings。

　　字体和文字的渲染也严重依赖于平台。WebKit中有两种不同Text Path: Fast and Complex。每一项都需要平台(port-side)支持。Fast只需要知道如何贴上位图轮廓(blit glyphs)就可以了，WebKit会为平台准备数据。而Complex则完全依赖于平台去处理，它仅仅请求:”请画出这个”。

　　“WebKit就像一个三明治，而 Chromium更像一个墨西哥玉米卷(taco)。” Dimitri Glazkov, ChromeWebKit hacker. Web Components和Shadow DOM的拥护者。

　　(为什么是taco,看这里就可以了.)

　　下表中列出了5个WebKit port的块图，了解一下它们之间的异同。

　　注意iOS上的Chrome使用的是系统控件UIWebView，因此它只能使用和Mobile Safari一样的渲染引擎(rendering layers)，以及JavaScriptCore和单进程模型(single-process model)。当然 Chromium还是有它的应用的， 诸如网络层(network layer),同步和书签的基础组件(sync and bookmarks infrastructure), Omnibox,metrics及崩溃报告(crashreporting). (之所值得这样做，是因为 JavaScript很少会成为移动端的瓶颈，而带有JIT的编译器的影响也会很小。)

　　WebKit浏览器间差异之大，何去何从?

　　大可不必!WebKit中提供了LayoutTest提供了大量的测试用例(28,000),不但针对已存在的功能，还包括回归测试。事实上，无论你何时发现了一些新奇的DOM/CSS/HTML5特性，LayoutTest通常已经提供了一个简化版的演示。

　　另外W3C也正增加其在页面一致性测试上的投入。这表示不同的WebKit ports和所有浏览器会针对相同的页面进行测试，将带来更少的私有特性(quirks)和更多可以共同操作的页面。

　　Opera将如何转换?

　　Robert Nyman和Rob Hawkes都分析过了,但值得注意的是Opera会采用Chromium。这表示WebGL, Canvas, HTML5 forms, 2D graphics等实现会和Chrome一样。相同的APIst和相同的后台(backends)实现。所以Opera是Chromium-based, Opera与Chrome会保持同步兼容。

　　并且所有Opera浏览器都会采用Chromium,甚至包括Opera Mini，会将原本Presto实现的在服务器端的渲染方式放弃，转而使用Chromium提供的渲染功能。

　　什么是WebKit Nightly?

　　它是WebKit的Mac Port，和Safari内部运行的版本是一致的(除了一小部分的基础库会被替换掉)。所以它的行为和功能是和Safari一致的。你也可以这样理解WebKit Nightly就是Safari,而Chromium就是Chrome。

　　Chrome Canary 也会与WebKit保持像是一天内的代码同步。