Chromeの新エンジンBlink ― Webプラットフォーム篇

よいサブタイトルが思いつかなかった。
Blinkでは、HTMLとかCSSとかDOMなどへの機能追加について、互換性、オープン標準、透明性を重視したガイドラインが設けられ、それが強くアピールされている。

Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.

今回はそれについて掘り下げていく。

ミッション:Webプラットフォームの前進

Blinkの目的は、Chromeの開発スピードやセキュリティを上げることだけではない。Blinkのプロジェクトページの最初にBlinkのミッションが書かれているんだけど、そこには「オープンWebを“technical innovation”と“good citizenship”により進めること」と書かれてある。

Blink's Mission:

To improve the open web through
technical innovation and good citizenship

“innovation”については、ここ数年の「HTML5」な動き、新しい機能を提案したり実装したり、そういうのが続いていくものと考えてよいだろう。
では、“good citizenship”についてはどうか。ひとつには、標準へのコミットがあるんだろう。これもこれまでやってきたことなので続いていく。ただ、それだけではない。これまでは、標準へのコミットメントはあっても、その実装や運用に課題があった。

ひとつのエンジンが進んでも、Webプラットフォーム全体が進むなんてことはない。部分的に、短期的にそう感じられるだけで、それによって生み出す負債があとできっと停滞をもたらす。

では、Blinkが“good citizenship”であるために取ろうとしているアクションは何なのか。

ベンダー接頭辞を廃し、ランタイムフラグでの制御に移行

ひとつは、もう説明不要かと思うけど…、新しい機能にベンダー接頭辞(-blink-foo)をつけないという方針だ。Blinkでは新しく導入される機能の試験実装にはランタイムフラグがつけられ、仕様もしくは実装が安定したと判断されるまで無効にされる。

これはポリシーとして明文化されなかったものの、WebKit時代でも実装中の機能については“Experimental WebKit Features”というランタイムフラグが導入され、運用されていた。これをちゃんと明記したということ。

このポリシー、Mozillaが昨年導入したものにかなりの影響を受けている。新しい機能については、仕様もしくは実装が安定するまではrelease channel, beta channelで無効にする。CSS ConditionalsやFlexbox, Masking, :scope などがそのポリシーのもと、実装はされるも無効にされている(Conditionalsについては仕様が先月末にCRに進んだため、Firefox 22では有効にされる予定。)

なお、このポリシーは既存のWebKit接頭辞つき機能について、接頭辞を省くというわけではない。残念だけど、もう省けない段階に来ている機能が多いだろう。ただ、Chromeのusage statsからその機能がどれくらい使われているかを調べる機能がWebKitにはあって、それを使っていくつかの接頭辞が実際に削除されていたので、削除できる機能もまだあるかもしれない。

「ランタイム」フラグ

これくらいは他でも書かれてるだろうから、もうちょっと細かいことも書いとこう。

Blinkのこの方針で気になったのが、「ランタイム」フラグとしているところ。WebKitにはfeature flagsという「コンパイルタイム」のフラグがあって、ビルドに含める機能を選べるようになっている。WebKitはportがあるので、各portによっては入れたくない、もしくはそもそも適さない機能をコンパイル時に選り分けられるようになっているのだろう。ちなみにChromeでも、CSS ConditionalsとかDevice Adaptationなど、ちょこちょことコンパイルタイムで無効にされた機能があった。

なんでだろうと思ったのだけれど、blink-devに答えがあった。“Removing #ifdefs”というスレッドで、Eric SeidelAdam Barthが、基本的にはランタイムフラグを使う方針だと言っている。コンパイル後のバイナリの大きさやパフォーマンスへの影響がある場合、コンパイルタイムフラグを使うかもしれないともあるけど、テストのしやすさなどもありランタイムフラグのほうが都合がよいらしい。

ふむむ。そうなると、“Experimental Web Platform Features”フラグ内にものすごい数の機能が入ることになる。これについてもさっきのblink-devのやつの派生スレッドで議論が始まっている。何が入ってるのかわかりづらいので個別のフラグのほうが好みなんだけど、chrome://flagsが長くなるからなあ。

「Webプラットフォーム」とはあるけれど、JavaScriptについてはV8の管轄になるため、今後も“Experimental JavaScript Features”を使うのかな。そういえば、MozillaはES6の機能についてはフラグも何もなしに有効にしてる気がする。作り的に難しいのか、べつにいいだろうって判断なのか。(追記:Mozillaのフラグについてteramakoさんとやり取りした。)

Chromium Feature Dashboardで現状を公開

接頭辞を廃したところで、Blinkに追加される機能が他のエンジンにも入らないと、Webプラットフォームは前進しない。かといって、他エンジンにコードを貢献するとかはほとんどできないだろう。

何が実装状況の差異を生み出しているのか。開発スピードやリリースサイクルの違いもあるだろうけれど、ベンダーの意思やプライオリティの違いが大きなファクターだろう。加えて、仕様の状態、Web開発者からのサポートも実装に少なからず影響する。

互換性を重視するなら、それらの状況確認は必須だろう。そこで活用されるのが、Chromium Feature Dashboardだ。

Chromium (WebKit) の実装状況はこれまでもWeb Platform Statusというページにまとめられていたんだけれど、あくまでChromiumの機能だけで、他のエンジンについては何も書かれていなかった。Chromium Feature Dashboardでは、仕様の状態、他のベンダーの実装状況や支持がまとめられている。

立ち上がったのは3月上旬なので、そんな新しくもないんだけれど、これがレンダリングエンジンの開発に影響するものになるとは。ちょっと驚き。

今のところ、Google spreadsheetsを埋め込んでいる。パーミッションをリクエストしたら、コメントしていろいろ指摘できるようになっている。ウォッチャーとしてのobligationを無駄に感じたので、早速コメントしている。

細かい内容はこれからつついてくとして、これいい。素晴らしい。(Chromiumが計画してない機能も載ったりするとウォッチャーとしてはありがたいけれど、それはまあ、なくてもいいか。)
Eric BidelmanがBy the way, watch for chromestatus.com to get much more robust in the coming months.と早くもv2についてほのめかしているので、これにも期待。

レビューを含むLaunch Process

機能の追加とリリースに至る過程については、Blinkプロジェクトページの“Launch Process”セクションにまとめられている。フローチャートもあるので、そっちを見たほうがわかりやすいかも。

「Webで使うAPIか」「新しい機能か」を見極めたのち、blink-devで機能追加したいというアナウンスをし、必要に応じて、トラッキングのためChromium Feature Dashboardの登録と、Type-Launch-OWPラベルつけたバグを投げる。

ここらへんは、去年からWebKitでも行われていた。透明性において必要だし、ウォッチャーにもやさしいので、Blinkでも継続してくれるのは嬉しい。

その後、実装、リリースと移るんだけれど、機能によっては実装前、リリース前にはAPI Reviewというのを行うらしい。基本的にはblink-devでコミュニケーションや合意をとるようにするけれど、それでも解決できないものがAPI Reviewミーティングで話されるとのこと。

実装だけではなくリリースにおいてもレビューを通すんだと思った。ソフトウェア開発に全然明るくないので、当たり前のことなのかもしれないけれど。

“OWP”

“OWP”ってなんだろう、まあ “Open Web Platform” の略だろうと思って調べたらやっぱりそうだった。どうやらOpen Wen Platform teamというのがあるらしい(ソース)。具体的に何をするのかがわからないけど、Chromiumの内部とかUIまわりではなくて、Blink (WebKit) の機能実装や標準化などに関わる人がいるのかな。

プロダクトマネージャーはAlex Komoroskeらしい。そうそう、彼がBlinkと互換性について熱く語ってるのでそちらも参照されたい。彼はQ&Aセッションでもなんかきゃっきゃしながら話していて面白かった。

OWPラベルの話にちょっと戻る。Launch Trackingのほか、新しいAPIの導入非公式な仕様しかない未レビューなものなど、サブラベルがいろいろある。ラベルのついたissueを見ると、ほとんどが3月9日につけられている。ふむ。

※ただし

新しい機能については、互換性への影響を考えた様々な取り組みをプロセスとして明文化した。
ただまあ、例外もあると。

互換性のリスクがリリースに足ると判断できない場合においても有効にしたい機能については、有効にすると。そのような場合は、標準化団体に対しeditor's draftを提供し、他のエンジンの実装者ともパブリックな場で議論することを要件としている。さらには、標準化においてもアクティブに貢献し、その結果発生しうるAPIの変更も受け入れると。例外なので、もちろん軽々しく当てはめてはいけないとも書いている。

他のベンダーが興味を示さない、もしくはプライオリティとして低く、タイミングが咬み合わない状況は生まれてしまうだろう。ドラフトは出ているけれどFileWriterやFileSystem APIなど、実質的にChromeの固有拡張となってるものもある。

感想とか

接頭辞を導入しないというポリシー、Feature Dashboardを推し出した透明性のアピール、例外においても最低限のことはする、などなど、だいぶかっこいい。Blinkさん。

例外は、独自拡張はこれまでもこれからも出てくるので、なんだよーとは思わない。穿った見方をするなら、接頭辞をつけないリスク、独自拡張への批判に対する保険なんだろう。Last resortであり続けるようにちょう頑張ってほしい。「例外()」みたいなことになりませんように。

接頭辞については、フォームの部品で使うShadow DOMへのアクセスについてどうするのか、すでに課題が出ている。先行き不安とまではいかないけど、どうするんだろう。

ただこのフォームのスタイリングについては、UIや見た目がプラットフォーム依存というのもあって、独自拡張の巣窟になっている。CSSのUIモジュールとか、標準化においてもなにか前進があるととてもうれしい。(このスレッドでは <select> のUIのいち部品のスタイルについて話しているので、標準レベルでは解決しづらい部分かなとは思うけれど。)


書きすぎた。

Blinkやその開発についての説明はここまで…と思いたい。
ただまだ、今後なににどんな影響をあたえるのか考えたものを書いてないので、次回はそれを。もうちょっとだけ続くのだよ……