開発者のための WebKit

WebKit port 間で共通なもの

• DOM, window, document
  • ほとんどの場合
• CSSOM
• CSS のパース、プロパティ・値の処理
  • ベンダー接頭辞の扱いを除いて
• HTML のパース DOM の構築
  • ちょっと Web Components のことを忘れれば同じ
• レイアウトとポジショニング
  • Flexbox, float, ブロック整形コンテクスト…は共通
• Chrome DevTools もとい WebKit Inspector の UI や中身
  • ただし、昨年4月から Safari は非 WebKit なクローズドソースな UI を Safari Inspector で使っている
• contenteditable, pushState, File API, SVG の大部分, CSS Transform の計算, Web Audio API, localStorage などの機能
  • ただしバックエンドが異なる。各 port は localStorage のストレージレイヤーで違うものを使うことがあるだろうし、Web Audio API でも異なるオーディオ API を使うことがあるだろう
• その他多くの機能

すこしぼやけてきたので、共通でないものを挙げてみよう。こちらはそれほどぼやけていない。

WebKit port 間で共通ではないもの

• GPU 上のものすべて
  • 3D Transforms
  • WebGL
  • ビデオのデコード
• スクリーンへの 2D 描画
  • アンチエイリアシングの方法
  • SVG & CSS グラデーションの描画
• テキストレンダリングとハイフネーション
• ネットワークスタック (SPDY, prerendering, WebSocket transport)
• JavaScript エンジン
  • JavaScriptCore は WebKit レポジトリにある。そして、WebKit には JavaScriptCore と V8 のバインディングが用意されている。
• フォームコントロールの描画
• <video> & <audio> 要素の挙動（とサポートしているコーデック）
• 画像のデコード
• 戻る・進むのナビゲーション
  • pushState() のナビゲーションに関わるところ
• Strict Transport Security や Public Key Pins などの SSL 機能

ひとつ紹介しよう。2D 描画 では、port ごとにまったく異なるライブラリを使用し、スクリーンへの描画処理を行なっている。

細かいところで言えば、最近実装された機能 CSS.supports() は win port と wincairo port 以外で有効にされている。これは、これら2つの port で CSS3 Conditional の機能が有効にされていないからだ。

ちょっと技術的な感じになってきたから、ちょっと細かいところをつつこうか。いま説明したことも、厳密には正しくない。共有されているものは、実際には WebCore なんだ。WebCore はレイアウト、レンダリング、HTML と SVG の DOM ライブラリで、みんなが “WebKit” と呼んでるものは基本的にこいつだ。では実際の “WebKit” は何かというと、WebCore と port のバインディングレイヤーを指す。まあ、ふつうの会話であればこの違いなんて、ほとんどどうでもいいんだけれど。

図で説明すると分かるかな。

WebKit 中の多くのコンポーネントが交換できるようになっている（灰色のところね）。

たとえば、WebKit の JavaScript エンジン JavaScriptCore。これは WebKit のデフォルトのエンジン（WebKit が KHTML を fork しスタートした際は、KDE の KJS をベースにしていた）。いっぽう、Chromium port では V8 に置き換わっており、さらに固有の DOM バインディングでマップしている。

フォントやテキストの描画はプラットフォームのとても大きな部分だ。WebKit は Fast path, Complex path という2つの text path を持っている。どちらもプラットフォーム固有（ポート側の）サポートを必要とするけれど、Fast path はただどのようにグリフをブリットするかを知るだけでよい（WebKit はそれをプラットフォームのためにキャッシュする）のに対して、Complex path は実際に全文字列をプラットフォームレイヤーに渡して「描画してくれ」と伝える。

WebKit はサンドウィッチのようなものだ。しかし Chromium においてはタコスに近い。そう、美味しい Web プラットフォームのタコスなのだ。 Dimitri Glazkov, Chrome WebKit hacker. Champion of Web Components and Shadow DOM

じゃあ、すこし広いところ、いくつかの port とサブシステムを見てみよう。次の表は5つの WebKit port についてまとめたものだ。WebCore の多くを共有していても、スタックが多種多様なことが分かるだろう。

* Chrome for iOS についての補足をしよう。分かってると思うけど、こいつは UIWebView を使っている。だから UIWebView が提供するもの、つまり Mobile Safari と同じレンダリングレイヤー、V8 ではなくて JavaScriptCore, そしてシングルプロセスモデルしか利用できない。しかし、ネットワークレイヤー、同期やブックマークのインフラ、Omnibox, メトリクスやクラッシュレポートなど、Chromium 側のコードもかなり利用している。（また、個人的な意見だけど、JavaScript がモバイルでボトルネックになることは非常に稀なので、JIT コンパイラが無いことのインパクトは限りなく小さいだろう。）

WebKit がそれぞれ違うのがわかって怖いよー

大丈夫！WebKit の layoutTest がカバーする範囲はとても広い（最後に見た時点で 28,000 以上）。テストは既存の機能に関するものだけじゃなくて、見つかったリグレッションについても用意されている。新しい、もしくは難解な DOM/CSS/HTML5 系の機能について調べるとき、layoutTest が小さくまとまったすばらしいデモになってることが多いんだ。

さらに、W3C は適合性テストへの取り組みを推し進めようとしている。つまり、異なる WebKit port やすべてのブラウザが同じテストスイートでテストされ、結果として変なバグの少ない、相互運用性が確保された Web になっていくんだ。この取り組みに関わるべく Test The Web Forward に参加したみんな、ありがとう。

Opera が WebKit に移行したけど、これからどうなるの？

Robert Nyman と Rob Hawkes が 触れているけど、Opera の発表で重要なことのひとつに、Opera が Chromium を採用したことがあると思う。つまり、WebGL, Canvas, HTML5 フォーム、2D グラフィックス実装、これらすべてが Chrome と Opera で同じように動作することになる。なぜなら、同じ API で, 同じバックエンド実装だから。Opera が Chromium ベースになるので、君がつくった最新技術のデモもすぐ Chrome と Opera で使えるようになる。

もうひとつ言いたいこと。Chromium を採用するのは すべての Opera ブラウザだ。だから Windows 版 Opera, Mac 版 Opera, Linux 版 Opera, Opera Mobile が Chromium ベースになる。さらにはシンクライアントの Opera Mini も、いまの Presto ベースなサーバサイドレンダリングファームを Chromium ベースに変更するんだ。

んーと、WebKit Nightly ってなに？

WebKit Nightly は Mac port の WebKit で、Safari が使うバイナリの中で動作する（ただ、内部のライブラリがいくつか差し替わってはいる）。だから WebKit Nightly の挙動や搭載している機能は将来の Safari と一緒だ。ざっくりと言えば、WebKit Nightly と Safari の関係は、Chromium と Chrome のそれみたいなものかな。

Chrome Canary も、ここ1, 2日の最新の WebKit ソースを使っている。

WebKit の中身についてもっと教えてよ！

ほーらよ、相棒！