-
Notifications
You must be signed in to change notification settings - Fork 1
/
webkit4devs.html
409 lines (327 loc) · 26.1 KB
/
webkit4devs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
<!doctype html>
<meta charset=utf-8>
<title>開発者のための WebKit (“WebKit for Developers” 日本語訳)</title>
<meta name=description content="Paul Irishの“WebKit for Developers”日本語訳です。WebKitと呼んでいるものは何か。異なるWebKit portで共通なもの、違うものについて紹介しています。">
<link rel=stylesheet href="lilium.css">
<link rel=license href="http://creativecommons.org/publicdomain/zero/1.0/">
<link rel=alternate href="https://github.com/myakura/n/commits/gh-pages.atom" type="application/atom+xml">
<script>
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-26017405-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<body>
<h1>開発者のための WebKit</h1>
<p class="note">このノートは、Paul Irishによる記事 <a href="http://paulirish.com/2013/webkit-for-developers/">“WebKit for Developers”</a> の日本語訳です。
<hr>
<p><img src="http://paulirish.com/assets/xwebkit-box.png.pagespeed.ic.hSgdM7e64A.png" alt="WebKit box logo" style="border: 0;
margin: 0;
box-shadow: none;
float: right;
vertical-align: top;">
僕ら開発者の多くにとって、<strong>WebKit はブラックボックスだ</strong>。HTML, CSS, JS, その他のアセットを投げると、WebKit は魔法でもかけたかのように、綺麗な Web ページを返してくれる。しかし、僕の同僚 <a href="http://www.youtube.com/watch?v=kiPe7DPmEgE">Ilya Grigorik は本当の WebKit はこうだと言っている</a>。
<blockquote>
<p>WebKit はブラックボックス<strong>ではない</strong>。ホワイトボックスなんだ。さらにそれだけではなく、<strong>オープンな</strong>ホワイトボックスなんだ。
</blockquote>
<p>じゃあ、これから次のことについて理解していこう。
<center>WebKit ってなに？
<br>なにが WebKit じゃないの？
<br>WebKit ベースのブラウザで WebKit はどう使われているの？
<br>なんですべての WebKit が同じじゃないの？
</center>
<!--
There are a few things all called, WebKit, so let's enumerate them first..
1. **WebKit the project**, where a bunch of hugely talented developers build one
of the leading implementations of the web platform
2. **WebKit the embedding API**, available for ports to embed the rendering
engine in their application
3. **WebCore**, which is what people think of when they say WebKit. (more on
that later…)
4. **WebKit the repository,** where code for the WebKit API, WebCore,
JavaScriptCore and more live.
5. and **WebKit, the perception**
Below I'll hop between a few of these definitions in my use of the word. It'll
work, trust me. :)
-->
<p>さて、世の中に数多くの WebKit ブラウザがあふれるようになった。とくに <a href="http://my.opera.com/ODIN/blog/300-million-users-and-move-to-webkit">Opera が WebKit に移行した</a>なんて話も新しい。ただ、それぞれの WebKit のどこが共通で、どこが違うのかを知るのはとても難しい。これからする説明で、それが少し分かるようになるだろう。そうなれば、ブラウザの違いについて今まで以上によく分かるし、適切なバグトラッカーに報告できるようにもなる。さらに特定のブラウザに対し、どうやって今まで以上に効果的に開発できるかを理解できるだろう。
<section>
<h2>標準的な Web ブラウザのコンポーネント</h2>
<p>今日のブラウザは、いくつかのコンポーネントから成り立っている。
<ul>
<li>パース（HTML, XML, CSS, JavaScript）
<li>レイアウト
<li>テキスト、グラフィックの描画
<li>画像のデコード
<li>GPU インタラクション
<li>ネットワークアクセス
<li>ハードウェアアクセラレーション
</ul>
<p>WebKit ベースのブラウザ間で、このうちどれが共通だろう？<strong>ほとんどの場合において、最初の2つだけだ</strong>。
<p>他のコンポーネントは、個々の WebKit port 側で扱われる。じゃあ、port って何だろう。
</section>
<section>
<h2 id="webkit-ports-explained">WebKit port とは</h2>
<p>WebKit には異なる “port” がある。ここでは Sencha の エンジニアリングディレクターで WebKit ハッカーの Ariya Hidayat に<a href="http://ariya.ofilabs.com/2011/06/your-webkit-port-is-special-just-like-every-other-port.html">説明してもらおう</a>。
<blockquote>
<p>WebKit としてよく紹介されるのが、Mac OS X 上で動作する Apple の WebKit だ（これは<a href="http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2">最初の、つまりオリジナルな</a> WebKit ライブラリだ）。そこから想像できる通り、この WebKit 上の様々なインターフェースは、Mac OS X 上の異なるネイティブライブラリを利用し実装されている（ほとんどの場合 <a href="http://developer.apple.com/corefoundation/%3Cbr%20/%3E">CoreFoundation</a> が中心だ）。たとえば、色のついたフラットなボタンに角丸を指定したとしよう。WebKit はどこから、そしてどのようにボタンを描画するかを知っている。しかし、最後のボタンの描画作業（ユーザのモニタ上に pixel でボタンを描くこと）は <a href="http://developer.apple.com/library/ios/#documentation/CoreGraphics/Reference/CoreGraphics_Framework/_index.html">CoreGraphics</a> の仕事になる。
</blockquote>
<p>ここで説明されている通り、CG は Mac port 特有の例だ。Mac の Chrome はこの場合 <a href="http://www.chromium.org/developers/design-documents/graphics-and-skia">Skia</a> を使う。
<blockquote>
<p>時が経ち、WebKit はデスクトップ、モバイル含め異なるプラットフォームに “port”（移植）された。これらは多くの場合 “WebKit port” と呼ばれる。Apple 自身も Windows 版の Safari の開発にあたり WebKit を移植し、Windows 上で動作するようにした。ここでは CoreFoundation ライブラリの <a href="http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html">Windows 版</a>（限定的な実装）を利用した。
</blockquote>
<p>…でも、Windows 版 Safari は<a href="http://www.macworld.com/article/1167904/safari_6_available_for_mountain_lion_and_lion_but_not_windows.html">終わっちゃった</a>けれど。
<blockquote>
<p>それ以外にも、多くの “port” が存在している（<a href="http://trac.webkit.org/wiki#WebKitPorts">一覧</a>をご覧あれ）。Google は Chromium port を開発し運用している。Gtk+ を元にした WebKitGtk というものもある。Nokia（が買収した Trolltech）は WebKit の Qt port を運用しており、とくに <a href="http://doc.qt.nokia.com/qtwebkit.html">QtWebKit module</a> として知られている。
</blockquote>
</section>
<section>
<h2 id="webkit-ports">代表的な WebKit port</h2>
<ul>
<li><strong>Safari</strong>
<ul>
<li>OS X と Windows の Safari は2つの異なる port だ
<li>WebKit nightly は Mac port の最新ビルドで、Safari に使われる。詳しくはあとで取り上げよう
</ul>
<li><strong>Mobile Safari</strong>
<ul>
<li>プライベートブランチで運用されているけど、最近 upstream され始めた <a href="http://trac.webkit.org/changeset/142163">[1]</a> <a href="http://trac.webkit.org/changeset/142373">[2]</a>
<li>iOS の Chrome（Apple の WebView を使用。違いについては後ほど）
</ul>
<li><strong>Chrome (Chromium)</strong>
<ul>
<li>Android 版 Chrome（Chromium port を直接使用）
<li>Chromium は <a href="http://browser.yandex.ru/">Yandex Browser</a>, <a href="http://se.360.cn/">360 Browser</a>, <a href="http://ie.sogou.com/">Sogou Browser</a>, それに（もうすぐ）Opera でも使われている
</ul>
<li><strong>Android Browser</strong>
<ul>
<li>その時点で最新の WebKit ソースを使用
</ul>
<li><strong><a href="http://trac.webkit.org/wiki#WebKitPorts">他の port</a></strong>: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, EFL port (Tizen), wxWebKit, WebKitWinCE, etc
</ul>
<p>port が独自のフォーカスを持つこともある。Mac port はブラウザと OS の分離にフォーカスし、そこに Obj-C と C++ バインディングを用意することで、レンダラをネイティブアプリに埋め込むことを可能にしている。Chromium のフォーカスは純粋にブラウザだ。QtWebKit はクロスプラットフォームな GUI アプリケーションアーキテクチャの中で、そのランタイム、もしくはレンダリングエンジンを提供するために port を提供している。
</section>
<section>
<h2 id="whats-shared">すべての WebKit ブラウザで共通なもの</h2>
<p>まず、すべての WebKit port で共有されている機能をおさらいしよう。
<aside>これ、書くのに何回もかかっちゃって。なんせ書くたびに Chrome team から指摘が入るんで。それでこんな感じに、はは……</aside>
<ol>
<style scoped>
em {
display: block;
font-size: .9em;
color: #666;
}
</style>
<li>まず、WebKit は HTML を同じやり方でパースする。
<em>※ ただし <a href="https://bugs.webkit.org/showdependencytree.cgi?id=106127&hide_resolved=0">threaded HTML parsing</a> を有効にした WebKit port（現時点では Chromium のみ）を除く。</em>
<li>うん……。で、パースが終わったら、DOM ツリーは同じように構築される。
<em>※ ただし Shadow DOM が <a href="http://goo.gl/dsXQf" title="Code Search for ENABLE(SHADOW_DOM) package:^chromium$ file:^src/third_party/WebKit/LayoutTests/platform/">有効にされた</a> port（現時点では Chromium のみ）を除く。なので DOM 構築も異なる。カスタム要素についても同じことが言える。</em>
<li>ええと……。あ、WebKit はどの port でも <code>window</code> オブジェクトと <code>document</code> オブジェクトを生成する。
<em>※ ただしそれらのプロパティやコンストラクタは <a href="https://trac.webkit.org/wiki/FeatureFlags">feature flag</a> の有効度合いによって異なる。</em>
<li>そうだね……。でも CSS パースは同じだ。CSS コードをズズッとすすって CSSOM にする。この方法はもうスタンダードだ。
<em>※ ただし Chrome は <code>-webkit-</code> 接頭辞のみをサポートするが、Apple や他の port は古い <code>-khtml-</code>, <code>-apple-</code> もサポートするという違いがある。</em>
<li>……。レイアウトとか…ポジショニングはどうかな？パンにバターみたいな組み合わせなんだし、どこでも同じだろう？ね！
<em>※ ただしサブピクセルレイアウト、飽和レイアウト演算は WebKit の一部にもかかわらず port ごとに違う。</em>
<li>だって。すごい。
</ol>
<p>というわけで、とても複雑だ。
<p><a href="http://code.flickr.net/2009/12/02/flipping-out/">Flickr</a> や <a href="https://github.com/blog/677-how-we-deploy-new-features">Github</a> が機能を有効フラグ付きで実装しているように、WebKit でも同じ事をしている。これによって port が <a href="https://trac.webkit.org/wiki/FeatureFlags">WebKit のコンパイルタイム Feature Flag</a> を使い、機能を有効・無効にできるようになっている。機能はランタイム flag として現れることもある。この場合は<a href="http://peter.sh/experiments/chromium-command-line-switches/">コマンドラインスイッチ（これは Chromium のもの）</a>や <a href="http://blogs.adobe.com/cantrell/archives/2012/07/all-about-chrome-flags.html">about:flags</a> みたいな設定から有効・無効にできる。
<p>じゃあ、今度こそ WebKit で何が共通なのかまとめてみよう……
<section>
<h3 id="webkit-common">WebKit port 間で共通なもの</h3>
<ul>
<li>DOM, <code>window</code>, <code>document</code>
<ul>
<li>ほとんどの場合
</ul>
<li>CSSOM
<li>CSS のパース、プロパティ・値の処理
<ul>
<li>ベンダー接頭辞の扱いを除いて
</ul>
<li>HTML のパース DOM の構築
<ul>
<li>ちょっと Web Components のことを忘れれば同じ
</ul>
<li>レイアウトとポジショニング
<ul>
<li>Flexbox, float, ブロック整形コンテクスト…は共通
</ul>
<li>Chrome DevTools もとい WebKit Inspector の UI や中身
<ul>
<li>ただし、昨年4月から Safari は非 WebKit なクローズドソースな UI を Safari Inspector で使っている
</ul>
<li>contenteditable, pushState, File API, SVG の大部分, CSS Transform の計算, Web Audio API, localStorage などの機能
<ul>
<li>ただしバックエンドが異なる。各 port は localStorage のストレージレイヤーで違うものを使うことがあるだろうし、Web Audio API でも異なるオーディオ API を使うことがあるだろう
</ul>
<li><a href="http://trac.webkit.org/browser/trunk/Source/WebCore">その他多くの機能</a>
</ul>
<p>すこしぼやけてきたので、共通でないものを挙げてみよう。こちらはそれほどぼやけていない。
</section>
<section>
<h3>WebKit port 間で<em>共通ではない</em>もの</h3>
<ul>
<li>GPU 上のものすべて
<ul>
<li>3D Transforms
<li>WebGL
<li>ビデオのデコード
</ul>
<li>スクリーンへの 2D 描画
<ul>
<li>アンチエイリアシングの方法
<li>SVG & CSS グラデーションの描画
</ul>
<li>テキストレンダリングとハイフネーション
<li>ネットワークスタック (SPDY, prerendering, WebSocket transport)
<li>JavaScript エンジン
<ul>
<li>JavaScriptCore は WebKit レポジトリにある。そして、WebKit には JavaScriptCore と V8 のバインディングが用意されている。
</ul>
<li>フォームコントロールの描画
<li><code><video></code> & <code><audio></code> 要素の挙動（とサポートしているコーデック）
<li>画像のデコード
<li>戻る・進むのナビゲーション
<ul>
<li>pushState() のナビゲーションに関わるところ
</ul>
<li>Strict Transport Security や Public Key Pins などの SSL 機能
</ul>
<p>ひとつ紹介しよう。<strong>2D 描画</strong> では、port ごとにまったく異なるライブラリを使用し、スクリーンへの描画処理を行なっている。
<p><img src="https://lh6.googleusercontent.com/--WfQB-Tr1sQ/TfHQSfY38FI/AAAAAAAAB8s/DSNAn8F71i8/s800/graphicscontext.png" alt="WebKit のグラフィックスレイヤー" style="display:block; margin: 0 auto;">
<p>細かいところで言えば、最近実装された機能 <code>CSS.supports()</code> は win port と wincairo port 以外で<a href="http://trac.webkit.org/changeset/142739">有効</a>にされている。これは、これら2つの port で CSS3 Conditional の機能が有効にされていないからだ。
<p>ちょっと技術的な感じになってきたから、ちょっと細かいところをつつこうか<!-- time to get pedantic. -->。いま説明したことも、厳密には正しくない。共有されているものは、実際には WebCore なんだ。WebCore はレイアウト、レンダリング、HTML と SVG の DOM ライブラリで、みんなが “WebKit” と呼んでるものは基本的にこいつだ。では実際の “WebKit” は何かというと、WebCore と port のバインディングレイヤーを指す。まあ、ふつうの会話であればこの違いなんて、ほとんどどうでもいいんだけれど。
<p>図で説明すると分かるかな。
<p><img src="http://paulirish.com/assets/webkit-diagram.png.pagespeed.ce.6jynYojf8j.png" alt="WebKit Diagram" style="display:block; margin: 0 auto;"> <!-- style="border: 0; margin: 0; box-shadow: none;" -->
<p>WebKit 中の多くのコンポーネントが交換できるようになっている（灰色のところね）。
<p>たとえば、WebKit の JavaScript エンジン JavaScriptCore。これは WebKit のデフォルトのエンジン（WebKit が KHTML を fork しスタートした際は、KDE の KJS をベースにしていた）。いっぽう、Chromium port では V8 に置き換わっており、さらに固有の DOM バインディングでマップしている。
<p>フォントやテキストの描画はプラットフォームのとても大きな部分だ。WebKit は Fast path, Complex path という2つの text path を持っている。どちらもプラットフォーム固有（ポート側の）サポートを必要とするけれど、Fast path はただどのようにグリフをブリットするかを知るだけでよい（WebKit はそれをプラットフォームのためにキャッシュする）のに対して、Complex path は実際に全文字列をプラットフォームレイヤーに渡して「描画してくれ」と伝える。
<blockquote id="dimitri-taco">
<style scoped>
cite:before {
content: "― ";
color: #999;
}
cite {
font-size: .9em;
}
</style>
WebKit はサンドウィッチのようなものだ。しかし Chromium においてはタコスに近い。そう、美味しい Web プラットフォームのタコスなのだ。 <cite>Dimitri Glazkov, Chrome WebKit hacker. Champion of Web Components and Shadow DOM</cite>
</blockquote>
<p>じゃあ、すこし広いところ、いくつかの port とサブシステムを見てみよう。次の表は5つの WebKit port についてまとめたものだ。WebCore の多くを共有していても、スタックが多種多様なことが分かるだろう。
<table id="wk-matrix">
<style scoped>
td:first-child {
width: 6em;
}
td ~ th {
width: 8em;
}
</style>
<tr>
<td></td>
<th>Chrome (OS X)
<th>Safari (OS X)
<th>QtWebKit
<th>Android Browser
<th>Chrome for iOS
</tr>
<tr>
<th>レンダリング
<td>Skia
<td>CoreGraphics
<td>QtGui
<td>Android stack/Skia
<td>CoreGraphics
</tr>
<tr>
<th>ネットワーク
<td>Chromium network stack
<td>CFNetwork
<td>QtNetwork
<td>Chromium network stack の fork
<td>Chromium stack
</tr>
<tr>
<th>フォント
<td>CoreText via Skia
<td>CoreText
<td>Qt 内部のもの
<td>Android stack
<td>CoreText
</tr>
<tr>
<th>JavaScript
<td>V8
<td>JavaScriptCore
<td>JSC (V8 は Qt のその他で利用)
<td>V8
<td>JavaScriptCore (JIT 無し) *
</tr>
</table>
<p><small>* Chrome for iOS についての補足をしよう。分かってると思うけど、こいつは UIWebView を使っている。だから UIWebView が提供するもの、つまり Mobile Safari と同じレンダリングレイヤー、V8 ではなくて JavaScriptCore, そしてシングルプロセスモデルしか利用できない。しかし、ネットワークレイヤー、同期やブックマークのインフラ、Omnibox, メトリクスやクラッシュレポートなど、Chromium 側のコードもかなり<a href="https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/vYGxPx-tVKE">利用している</a>。（また、個人的な意見だけど、JavaScript がモバイルでボトルネックになることは非常に稀なので、JIT コンパイラが無いことのインパクトは限りなく小さいだろう。）</small>
</section>
</section>
<section>
<h2>わかった。それでどうなるの？</h2>
<section>
<h3>WebKit がそれぞれ違うのがわかって怖いよー</h3>
<p>大丈夫！<a href="http://trac.webkit.org/browser/trunk/LayoutTests">WebKit の layoutTest がカバーする範囲</a>はとても広い（最後に見た時点で 28,000 以上）。テストは既存の機能に関するものだけじゃなくて、見つかったリグレッションについても用意されている。新しい、もしくは難解な DOM/CSS/HTML5 系の機能について調べるとき、layoutTest が小さくまとまったすばらしいデモになってることが多いんだ。
<p>さらに、<a href="http://www.w3.org/QA/2013/02/testing_the_open_web_platform.html">W3C は適合性テストへの取り組みを推し進めようとしている</a>。つまり、異なる WebKit port やすべてのブラウザが同じテストスイートでテストされ、結果として変なバグ<!-- fewer quirks -->の少ない、相互運用性が確保された Web になっていくんだ。この取り組みに関わるべく <a href="http://testthewebforward.org/">Test The Web Forward</a> に参加したみんな、ありがとう。
</section>
<section>
<h3>Opera が WebKit に移行したけど、これからどうなるの？<!-- How does that play out? --></h3>
<p>Robert Nyman と Rob Hawkes が <a href="http://robertnyman.com/2013/02/14/webkit-an-objective-view/">触れている</a>けど、Opera の発表で重要なことのひとつに、<strong>Opera が Chromium を採用した</strong>ことがあると思う。つまり、WebGL, Canvas, HTML5 フォーム、2D グラフィックス実装、これらすべてが Chrome と Opera で同じように動作することになる。なぜなら、同じ API で, 同じバックエンド実装だから。Opera が Chromium ベースになるので、君がつくった最新技術のデモもすぐ Chrome と Opera で使えるようになる。
<p>もうひとつ言いたいこと。Chromium を採用するのは <a href="http://twatlr.com/thread/301603979257856000"><strong>すべての</strong> Opera ブラウザ</a>だ。だから Windows 版 Opera, Mac 版 Opera, Linux 版 Opera, Opera Mobile が Chromium ベースになる。さらにはシンクライアントの Opera Mini も、いまの Presto ベースなサーバサイドレンダリングファームを Chromium ベースに変更するんだ。
</section>
<section>
<h3>んーと、WebKit Nightly ってなに？</h3>
<p>WebKit Nightly は <a href="http://trac.webkit.org/browser/trunk/Source/WebKit/mac">Mac port</a> の WebKit で、Safari が使うバイナリの中で動作する（ただ、内部のライブラリがいくつか差し替わってはいる）。だから WebKit Nightly の挙動や搭載している機能は将来の Safari と一緒だ。ざっくりと言えば、WebKit Nightly と Safari の関係は、Chromium と Chrome のそれみたいなものかな。
<p><a href="http://paulirish.com/2012/chrome-canary-for-developers/">Chrome Canary</a> も、ここ1, 2日の最新の WebKit ソースを使っている。
</section>
<section>
<h3>WebKit の中身についてもっと教えてよ！</h3>
<p>ほーらよ、相棒！
<p><a href="https://docs.google.com/presentation/d/1ZRIQbUKw9Tf077odCh66OrrwRIVNLvI_nhLm2Gi__F0/embed?start=false&loop=false&delayms=3000"><img src="http://paulirish.com/i/x3fb890.png.pagespeed.ic.6nLbkKT48f.png" alt=""></a>
</section>
</section>
<section>
<h2>あわせて読みたい</h2>
<ul>
<li><a href="http://www.webkit.org/coding/technical-articles.html">WebKit internals technical articles | webkit.org</a>
<li><a href="http://robertnyman.com/2013/02/14/webkit-an-objective-view/">WebKit: An Objective View | Robert Nyman & Rob Hawkes</a>
<li><a href="http://ariya.ofilabs.com/2011/06/your-webkit-port-is-special-just-like-every-other-port.html">your webkit port is special (just like every other port) | Ariya Hidayat</a>
<li><a href="http://blogs.adobe.com/webplatform/2013/01/21/getting-started-with-the-webkit-layout-code/">Getting Started With the WebKit Layout Code | Adobe Web Platform Blog</a>
<li><a href="http://arunpatole.com/blog/2011/webkit-documentation/">WebKit Documentation Overview | Arun Patole</a>
<li><a href="http://www.youtube.com/watch?v=RVnARGhhs9w">Rendering in WebKit, by Eric Seidel | YouTube</a>
<li><a href="http://www.igvita.com/slides/2012/web-performance-for-the-curious/">web performance for the curious | Ilya Grigorik</a>
</ul>
</section>
<p>この記事で WebKit ブラウザの内部について説明でき、またどこからどこまでを WebKit, どこからどこまでが WebKit port なのかを伝えられたら嬉しい。
<hr>
<p>Reviewed by Peter Beverloo (Chrome), Eric Seidel (WebKit). <br/>
I’ll update with any corrections or modifications.
<div class="update">
<ul>
<li> 8:30am. Removing the slides embed because it’s making Firefox scroll to its position.
<li> 9:50am. Chrome for Mac’s font rendering in Skia uses CoreText to draw
glyphs, so it’s more like CoreText via Skia. (thx thakis!)
<li> 10:49am. Fixed broken link and typo. (thx tim!) Fixed weird meta description choice.
<li> 3:00pm: Mike West pointed to Levi Weintraub’s sweet & <em>detailed</em> <a href="http://www.youtube.com/watch?v=GGzmST5nNSM">What is WebKit?” presentation (video)</a>. <a href="http://www.slideshare.net/naseemh/airbnb-tech-talk">slides</a>
<li> 4:00pm. tonikitoo, hacker on QtWebKit wanted to clear up some subtleties:
<blockquote style="font-size: 12px">Nokia (through Trolltech, which it acquired) maintains the Qt port of WebKit, popular as its QtWebKit module. It might be valuable to mentioned that Digia acquired the Trolltech/Qt division of Nokia and now maintains QtWebKit. Also, not to be too nit-picker, in your subtitles “Some of the ports of WebKit” I would have said “Some of the Products running on top of specific ports of WebKit” because strictly speaking Safari is not a port, but a “Browser that makes use of the Apple WebKit port on Mac”.</blockquote>
True.
<li>5:00pm. <a href="http://myakura.github.com/n/webkit4devs.html">This article has been translated into Japanese</a>. Thanks Masataka Yakura!
<li>2013-03-06: <a href="http://ued.taobao.com/blog/2013/03/webkit-for-developers/">This article has been translated into Chinese</a>
</ul>
</div>
<footer>
<address>by <a rel=author href="http://profiles.google.com/117261322300109492957">Masataka Yakura</a></address>
<p class=update>Published: March 1, 2013 / Last update: March 9, 2013
</footer>