原文:http://www.paulirish.com/2013/webkit-for-developers/css
Paul Irish 大溼爲咱們帶來了這篇開年大做,文章深刻淺出的闡述了各 Webkit port 的迥異。文筆細膩,是一篇不可多得的 Webkit 入門開胃菜。html
爲了讓你們第一時間更好的品嚐這道大菜,@一絲yisi 特別邀請了幾位 Webkit 專業開發人士做爲本文的翻譯顧問,在此表示由衷的感謝。ios
本文涉及到許多的專業術語。我會盡可能補充一些相關資料的連接。翻譯不當之處。歡迎批評指正。css3
對於不少開發人員而言,WebKit 是一個黑盒子。咱們把 HTML, CSS, JS 和一堆資源放進去,而後 WebKit 以某種方式。奇異地變出一箇中看又中用「美觀而有用」的網頁。其實,如同我同事 Ilya Grigorik 所說 …git
WebKit 它不是一個黑盒子。而是一個白盒子,並且是一個開放的白盒子。github
那麼讓咱們花一點時間來理清一些東西:web
WebKit 是什麼?算法
WebKit 不是什麼?chrome
基於 WebKit 的瀏覽器使怎樣運用 WebKit ?windows
爲何所有的 WebKit 並不同「呢」?
儘管現在咱們已經有了很是多 Webkit 瀏覽器了,特別是有消息稱 Opera 也已經轉移到 WebKit 了,但是想要理解他們的一樣點和不一樣點仍是挺難的。如下我將側重講這方面,你將能更好的分辨瀏覽器的差別。在合適的 bug 跟蹤系統提交 bug,並瞭解怎樣更加高效的針對特定的瀏覽器進行開發。
標準的 Web 瀏覽器組件 讓咱們看一下現代 web 瀏覽器的幾個組件:
那麼哪些是基於 WebKit 的瀏覽器所共享的呢? 差點兒僅僅有前兩項。
其餘的由各自的 WebKit port 負責。讓咱們回想下這意味着什麼? WebKit Port 儘管 Webkit 有不一樣的 」port」,但請贊成我引用來自 Sencha 的 WebKit hacker 兼 eng 主管— Ariya Hidayat 解釋一下 :
WebKit 最多見的參考實現是 Apple 本身的執行在 Mac OS X 上的WebKit 實現(這也是最先最原始的 WebKit 庫)。正如你所知。在 Mac OS X 上各類接口的實現使用不一樣的本地庫,大多集中在 CoreFoundation 。比方,你定義了一個帶有特別的圓角的平面彩色button。那麼 WebKit 會知道在哪裏以及怎樣畫繪製這個button。可是。終於實際畫繪製button的職責(做爲用戶顯示器上的像素)仍是落到了 CoreGraphics 身上。
如上所述。僅僅有 Apple 本身在 Mac 上的實現是使用 CG。Chrome 在 Mac 上的實現使用的是 Skia。
隨着時間推移,WebKit 被移植到不一樣的平臺,包含桌面和移動端。這樣的作法一般被稱做「一個 WebKit port」。對於 Safari 瀏覽器的 Windows 版本號。Apple 也把本身的 WebKit 移植到 Windows 上。同一時候使用 Windows 版(閹割版)的 CoreFoundation 庫。
雖然 Windows 版 Safari 現在掛了 。
此外,還有更多的」port」(查看
全部的列表)。Google 建立了一個持續維護的 Chromium port。
還有。這是基於 GTK + 的 WebKitGtk。Nokia(經過它收購的 Trolltech 公司)維護 Qt 的 WebKit 移植版本號,通常叫作QtWebKit 模塊。
(譯者注:後來又廉價賣了,現在 Qt 屬於 Digia 公司)
一些 WebKit port
(譯者注:upstream 是開源項目的術語。指其餘人或者公司從主幹代碼開出來的私有分支的代碼又一次提交回主幹)
不一樣的 port 可以有不一樣的側重點。
Mac port 關注的是瀏覽器內核和操做系統相關的實現部分的分離,它經過 Obj-C 和 C++ 代碼把(WebKit)渲染引擎嵌入到本地應用中。 Chromium 則不少其餘關注瀏覽器自己。而 QtWebKit 則把它的 WebKit 實現做爲一個執行時的庫或者渲染引擎,同其跨平臺 GUI 應用程序框架一塊兒提供給其餘應用使用。
哪些是所有 WebKit 瀏覽器所共享的?
首先,讓咱們回想一下所有 WebKit port 的共同點。
這很是有趣,我試着寫了幾回。
每次都會被 Chrome 團隊成員斧正,正如你將會看到的……
1. 首先,WebKit 以相同的方式解析 HTML 。
好吧,除了 Chromium。它是迄今爲止惟一支持 threaded HTML 解析的 port(譯者注:Last week in WebKit: Threaded HTML parser and background blending)。
2.然而一經解析,DOM 樹構造依舊相同。因此,實際上僅僅有在 Chromium port 中 Shadow DOM 被打開的狀況下, DOM 結構纔會改變。固然這相同適用於本身定義元素。
3. WebKit 都會建立了一個 window 對象和 document 對象。
使得經過它暴露出來的屬性和構造器(譯者注:某種函數)可以在 feature flags 選擇打開。
4.CSS解析基本是同樣的,把你的 CSS 文件解析成(內部的)CSS 對象模式仍是一個比較標準的過程。
是的。雖然 Chrome 僅接受 -webkit- 前綴,然而 Apple 和其餘的 port 接受遺留前綴像 -khtml- 和 -apple-。
5.排版。定位?好吧。也來點麪包和黃油吧!
Sub-pixel layout 和 saturated layout (譯者注:已經加入連接)算法是 WebKit 的一部分,但是各 port 之間存在差別。
6. 好極了。
因此,事情很是複雜。
就像 Flickr 和 Github 經過 flags 標識實現特性,WebKit 也是這麼作的。贊成 port 經過 WebKit 的編譯特性標識 。 啓用或禁用各類功能。這些特性可以做爲執行時標識被暴露,也可以經過命令行開關(Chromium 是這樣) ,或者經過配置 about:flags 。
好吧,讓咱們又一次概括下各 WebKit 的共同點……
WebKit port 的共同點
哪些是 WebKit port 不共享的
看如下這些: 2D 圖形方面依賴於不一樣的 port 。咱們用全然不一樣的庫把它繪製到屏幕上:
或者更微觀一點,近期的新特性:CSS.supports() 除了 win 和 wincairo, 所有的 port 都可用 ,同一時候它們沒有啓用 css3 conditional (css3 特性檢測)特性。
既然咱們瞭解了這些,是時候更加深刻一些了。
其實以上的敘述是不對的。 WebCore 是共享的。WebCore 是一個針對 HTML 和 SVG 的排版、渲染和文檔對象模型(DOM)的庫,它就是人們一般所說的 WebKit 。實際上「WebKit 」是 WebCore 和 port 的綁定層。雖然在扯淡時這樣的差異是不重要的。
下圖應該有所幫助:
WebKit 裏面不少的組件是可交換的(上圖灰色區域)。
舉個樣例。起初,WebKit 的默認 JavaScript 引擎是 JavaScriptCore 。
(它基於最初的 KJS (源於 KDE)。WebKit 開始僅僅是 KHTML 的一個 fork 分支)。
後來,Chromium port 替換爲 V8,而後使用獨立的 DOM 綁定機制映射上去就完事了。
字體和文本渲染佔一個平臺的很是大一部分。WebKit 有2個單獨的文本路徑:高速(Fast)和複雜(Complex)。
二者都需要平臺特定(port-side)的支持,但高速僅需要知道怎樣 blit glyphs (傳輸符號)(WebKit 爲平臺作了緩存)。複雜確實需要轉換整個字符串到平臺層而後說「請繪製這個」。
WebKit 像一個三明治。雖然在 Chromium 中更像墨西哥玉米卷。一個美味的 web 平臺玉米卷。
」——Dimitri Glazkov。Chrome WebKit hacker。Web 組件和 Shadow DOM 的擁護者。
現在。讓咱們放大鏡頭看看一些 port 和一些子系統。如下是 WebKit 的5個 port。雖然它們共享WebCore 的大部分,但它們的 stacks 是不一樣的。
* iOS 版 Chrome 註解:你可能知道它使用 UIWebView,由於 UIWebView 的能力意味着它僅僅能使用像移動版 Safari 那樣的渲染層。JavaScriptCore (替代 V8)。單進程模式。
雖然如此,大量的 Chromium 代碼起銜接做用 ,好比網絡層,同步和書籤基礎設施,地址欄,度量和崩潰報告。(同一時候,更重要的是,JavaScript 很是少成爲移動端的瓶頸,缺少 JIT 編譯器(譯者注:具體資料)僅僅有很是小的影響。)
好吧。那麼咱們該怎麼辦? 現在所有 WebKit 全然不一樣了,我弱弱的表示懼怕。
不是必需!
WebKit 的 layoutTests 覆蓋面很廣(最新統計是28,000 個 layoutTests),不只針對已存在的特性。而且針對不論什麼發現的迴歸。實際上,每當你探索一些新的或難懂的 DOM/CSS/HTML5 特性時。layoutTests 常常已經有了奇異的最小化的演示樣例。
此外,W3C 正在努力研究一致性測試套件 。
這意味着咱們可以期待不一樣的 WebKit port 和所有瀏覽器使用相同的測試套件測試,帶來更少的怪癖模式和更彼此協做的網絡。所有參加過 Test The Web Forward 大會(譯者注:比方去年在北京的分會場) 爲此作出努力的人們,謝謝大家。
Opera 剛剛轉移到 WebKit了。有何影響呢?
Robert Nyman 和 Rob Hawkes 也談到了這個 ,但是我將補充一些:Opera 公告的一個明顯的部分是 Opera 將採用 Chromium。這意味着 WebGL。Canvas。HTML5 表單,2D 圖像實現——所有這些 Chrome 和 Opera 將保持一致。
相同的 APIs。相同的後端實現。由於 Opera 是基於 Chromium,你可以深感自信。你將來的工做可以同一時候兼容 Chrome 和 Opera 。
我也應該指出所有的 Opera 瀏覽器 將採用 Chromium。所以 Windows。Mac 和 Linux 版 Opera,以及 Opera Mobile(全然成熟的移動瀏覽器)。甚至 Opera Mini 輕client。將使用基於 Chromium 的渲染替換當前的基於 Presto 的server端渲染。
WebKit Nightly。是什麼?
它是 WebKit 的一個 mac port ,內部執行跟 Safari 同樣的二進制文件(雖然會替換一些底層庫)。所以它的行爲和特性跟 Safari 全同樣。假設你想回到從前,可以考慮它……總之。WebKit Nightly 面向 Safari 。 Chromium 面向 Chrome 。 Chrome Canary 包括最進一兩天以內的 WebKit 資源。