新しいSafariについて予想する

Safari WebKit

追記 (2013-08-13): WWDCでの発表にて、いくつか予想が外れたのが分かったので、短い答え合わせのエントリを書いた。あわせてSafariに懸念していることも書いたので、それもどうぞ。

以下は元記事。

WWDCが近いので新しいSafariの予想をしようかと。
来週まで待って確定的な情報を書いてもよかったけど、まあいいや。

たぶん7月に出る

新しいバージョンが「Safari 7」になるのかわかんないから、Apple風に「新しいSafari」と書くね。

ここ2回のメジャーバージョン（5.1, 6.0）は、7月下旬にリリースされている。なので今回も、WWDCでお披露目＋Developer Previewのリリース、7月の同時期に正式版リリースされると予想。

ここ1, 2ヶ月のWebKitでのAppleの動きを見ても、コードのリファクタリングや細かなバグ修正、あとChromeのBlink移行に乗じたコード削除がほとんどな印象がある。なので、リリース準備に入っているんじゃないかと。

あと、ブランチが5月22日に切られた。

safari-537.43-branchという、メジャーバージョンが537になってから、初のブランチ（なはず）。trunkからのマージも行われている。

過去のSafariのブランチも調べてみると、Safari 6.0の元になった536ブランチが切られたのは2012年5月7日、Safari 5.1の元になった534ブランチから派生している。これが2011年5月20日。2週間ばらついてるけど、5月中に行われている。

今回はマイナーバージョンも含めたブランチなので、過去2回とちょっと違うけど、でもこれが新しいSafariのベースになるんじゃないかなと。

なにが入る？

Changesetのメモやコンパイルタイムフラグから拾ってみる。Nightlyで試すのがよいのだろうけど、ちょっと時間かかりそうなので省略。間違ってたらごめんなさいよ。

新しい機能

Page VisibilityはChromeにはあったけど、これまでSafariでは有効にされていなかった。Changesetには[iOS]とあるけれど、デスクトップで使えないなんてことはないと思う。
ちょっと面倒なのが、Blinkではまだ接頭辞がとれてないけど、WebKitでは接頭辞が削除されてしまったこと。webkitHiddenで壊れるWebというのは想像できないけど、どうなんだろう。なんにせよBlinkがんばって。

backgroundでのbackground-sizeサポートでは、backgroundにあったバグが修正されたので、background-sizeの後にbackground書いてたら問題が出るかと思う。あったら修正しよう（background-sizeを後に書こう）。

あと、WebGLも有効になるんじゃないかと思っている。IE11で対応しそうなこのご時世にSafariは対応しないとかね、ないと思うんですよ。Google MapsだってWebGLベースになるのに…あっMapsだからもしかして…いやいや。iOSやWebViewはわかんないけど、デスクトップでは使えるようになるのではないか。

Speech Synthesis APIは何するつもりなんだろう。接頭辞もない。APIは固まってるのかな。

接頭辞つきの新機能（独自拡張、試験実装）

Flexboxはつつくとバグがぼろぼろ出てきそうな気がする（特に他の機能と組み合わせると）。Flexbox, 今年中には本格的に使えるかなと思ったけど、そこまでな感じがしなくなったのが残念。OperaのChromium移行で実装がたぶん後退したこと、Firefoxではmultiline Flexboxほかいくつかの機能が未実装ので、接頭辞無しでフルに使えるブラウザは後発のIE11だけになるんじゃないかというこの面白さ。

-webkit-cursor-visibility: auto-hideはビデオとか、フルスクリーン時にマウスカーソル消したい場合に使うらしい。簡単に試したけど、フルスクリーン時しか動作しない感じ。そりゃそうか。

-webkit-fit-contentは「要素内容に依存する幅の指定について」で説明されてるのでそちらをどうぞ。仕様はcss-boxよりもcss-sizingを見たほうがいいかも。

接頭辞がとれた機能（接頭辞つきのも引き続きサポート）

Gradients, Transitions, calc()が接頭辞なしで使えるのは大きい。グラデーションは、これまでさんざん言ってきたけど、構文が変わったので気をつけたい。

あとはTransforms, Animationsか…大掛かりそうだけれど、来年までにはなんとかしてほしいなあ。

接頭辞つき実装が削除された機能

先々月のWebKit Contributors Meetingで、機能の削除とか接頭辞まわりのスロットがあって、そこで接頭辞は可能な限り削除していく大方針が決まったみたい。大きく進展する気はしないけど、去年くらいからぽつぽつと成果が出ているのはよいこと。

バグ修正で気になったものなど

-webkit-text-size-adjustがデスクトップで無効になったので、ズームしてもフォントサイズが変わらないとかがなくなったはず。メディアクエリーのやつは、em-based queryでRWDなサイト作ってるとき問題になってたやつ。

border-radius絡みはようやくか、という感じ。classListと画像のオフセットのやつはバグの存在を初めて知った。

入らない（だろう）機能

コンパイルタイムフラグのファイルより、入らなそうな機能の一部を。

  • Web Components
  • Performance系API（*** Timings, High Resolution Time）
  • Scoped Stylesheets
  • CSS Exclusions, Shaders, Compositing
  • <iframe seamless>
  • Shared Workers
  • CSS Device Adaptations
  • CSS resolution media feature
  • IndexedDB

いろいろない。無理ないなって機能もあるけど、Scoped Stylesheetsは入れて欲しかった……

High Resolution Timeは一度入ったんだけど、performance.now()だけの判定で他のPerf系APIが使えると想定してるコードがあったようでrevertされてしまった。Timing系を入れるって選択肢はないらしい。ちぇっ。

High Resolution Time入らなかったらrequestAnimationFrame()のコールバックが取る引数ってどうなるんだろう。

残念な部分や細かな疑問は尽きないけれど、どのブラウザにもこれ入ってほしいなあというのはあるし、そんなものだよね。あとAppleが保証できない・するつもりもない機能をSafariに入れてしまうのは、それはそれで問題だろう。いまだって、中途半端な実装に泣かされていたりもするんだから。とくにWebKitみたくいろんなベンダーが関わるプロジェクトだと、そういう状況になりやすいだろうから、機能は減っても、安定するまでは使えないようにしとくのはよいかなと思う。

政治的に入ってない機能については、Webサイト・Webアプリ側で無理やり使っていって依存させ、実装せざるを得ない状況にもっていくしかないんだろうか。

Blinkでメディアクエリーのwidth/heightがスクロールバーを含むように

Blink WebKit Chrome CSS

Chrome 28がBetaに移った。表面上とくに違いはないだろうけれど、BlinkなChromeですよ。

さて、タイトルで言ったとおりの変更がBlinkに行われた。

M28に入るかなと思って試したんだけど、そう動かなかったのでこれはM29からになりそう。Stableまでは3ヶ月ほど猶予があるから、入らなくてよかったかも。

ええと、どういうことかというと、もし、

  1. RWDなどメディアクエリーを使うサイトを作っていて
  2. クエリで width (あるいは height) を使っていて
  3. ChromeもしくはSafariをメインに作っていて
  4. そのサイトをFirefox, Opera, IEでテストしていない

という場合、ブレークポイント前後で予期せぬ横スクロールバーが出る可能性があるのでお気をつけくださいというおはなし。

仕様のおさらいとWebKitのバグ

メディアクエリー仕様では媒体特性 width, height について、スクロールバーがある場合、その幅を含めた値が媒体特性のとる値と定義されている。

The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any).

Gecko, Presto, Tridentはこれにしたがって実装しているのだけれど、WebKitのメディアクエリー実装には width, height がスクロールバーの幅を含めないっていうバグがある。

これがBlinkにも引き継がれたのだけれど、最初に書いたようにちょっと前に修正されたと。

Macだと気が付きにくい

この挙動、Media query width and vertical scrollbars demo pageにて確認できる。ただ、Macだとめんどくさい。

スクロールバーの幅を含めると書いたのだけれど、Lionからはスクロールバーがオーバーレイなものになった。このスクロールバーは、ページや要素の幅/高さに影響していない。Chrome/Safariをメインに〜と書いたのはそういう理由。

System Preferences→General→“Show scroll bars”から“Always”を選択すればスクロールバーを表示させられるので、ちょっと面倒だけれどどうぞ。

もっとも、楽なのはFirefoxかOpera (Presto)で試してみること。どちらも現時点で仕様に準拠していて、かつオーバーレイスクロールバーを実装していないのでどうなるかがわかる。あと、そろそろスクロールバー何とかしろよという話については、すでにAuroraだとオーバーレイスクロールバーになっているので、もうちょっと待たれいですよ。

直さなくてもいいような気をつけたいような

問題意識高いひと（めんどくさい）なのでくどくど書いたけれど（めんどくさい）、そんな大した問題でもないかなとも思う（めんどくさい）。

あまりに幅にピーキーなつくりにしてなければ、だいたい大丈夫じゃないかなと。あと、Firefoxとかでチェックしてたら、そう起こらないと思うので。
問題があったとしても、ブレークポイント前後でウインドウ幅びろびろさせたりする人はWeb制作者以外にはそういないだろうから、気にしなければそれまで、でいいんじゃないかなと。

ただ、JavaScriptでページの幅とって何かしたりするものがあると、15px前後（スクロールバーの幅ぶん）ずれが生じるかもしれない。

あと、そんなないと思うけど、matchMedia() にマッチさせたい幅からスクロールバーぶん引いた値をクエリとして渡してる場合は書き換えないといけない。

ぐうぐうたらら

viewport（metaのじゃないほう）においてはスクロールバーの幅を含めないほうがsensibleなんじゃないかとも思わなくないけど、CSSがsensibleであったことなんてないのでこれについては諦めてもらうしかない……。

“responsive”と呼ぶサイト作ってて、幅に敏感すぎるつくりは気が利いてないってことなので、ちょっとゆるめに。ピクセルセントリックだと、ちょっと難しいのかもだけど。

Opera 14デスクトップ版がいま出てしまうと、Chrome 26ベースなので、後退するのが切ないところ。早く出てほしいけれど……。

このパッチWebKit側でマージできたりしないだろうか。OS X/iOSでは影響しなくても、他のWebKitなブラウザでは影響するので。

BlinkなChromeのExperimental Features

Blink Chrome

3月にChromeのExperimental WebKit/JavaScript Featuresというのを書いたらGoogle+でけっこうな反響があった。BlinkのFAQからも間接的に参照されてたりしている。ただ件のエントリを書いたのはChromeがまだWebKitを使っていたとき。その後Blinkになり、ランタイムフラグの重要性が増し、コードもちょっと変わったので、アップデートを。

RuntimeEnabledFeatures.inにまとまり始める

試験実装は基本的にコンパイルタイムフラグではなくランタイムフラグを使う方針というのは、Blinkの紹介で書いた。その時はcontent/renderer/render_thread_impl.ccとcontent/browser/web_contents/web_contents_impl.ccという2ファイルから探さないといけなかったのだけれど、それがcrbug.com/237740 - Autogenerate Runtime Feature systemにて整理された。

TL;DR: If you're adding/removing runtime-guarded features, use RuntimeEnabledFeatures.in:
https://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in

とのこと、RuntimeEnabledFeatures.inはChromiumではなくてBlinkの方にある。

ただ、そこに書かれてる機能がすべてExperimental Featuresなのかというとそうではないのでちょっと注意。ファイル冒頭のコメントにもあるけれど、各機能にはステータスが書かれている。stable, experimental, test という値が用意されていて、それぞれ「Stable Channelで有効」「Experimental Featuresフラグで有効（でもStableでは利用不可）」「Content Shellでのテストのみに限定（なんでフラグ有効でも使えない）」を意味しているみたい。値がないものは、無効と。

web_contents_impl.ccの機能は未統合

というわけで、BlinkでのExperimental FeaturesはRuntimeEnabledFeatures.inから experimental なものを探せばよい……と思ったんだけど、このファイルにはweb_contents_impl.ccにある position: -webkit-stickyやらがない。なのでweb_contents_impl.ccは引き続き見ないといけなそう。ただ入ってる機能を見ると、短期的中期的に有効にはされなそうなものが多い感じ。

JavaScriptは引き続きV8のファイルを

見出しの通り、JavaScript絡みはV8のファイルflag-definitions.hから探す。Webの機能ほどガンガン追加されてく感じはあまりしないけれど、既報の通り最近generatorsが追加されたりしているので、たまに見とくと面白そう。

追記 (2013-08-24): Chrome 30からフラグ名が変更に

Chrome 30から、長らくWebKitとついてたフラグ名が変更され、“Enable experimental Web Platform features”になった。

chrome://flags/#enable-experimental-web-platform-featuresから有効にできる。フラグ名が変わったので、WebKitなフラグを有効にしてたとしても、再度設定しないと新しい機能が試せないようになっているはず。

追記 (2018-04-16): いまはファイルが違う

RuntimeEnabledFeatures.inはその後runtime_enabled_features.json5というファイルに変換された。

機能の利用度合いを測るUseCounter (FeatureObserver)

WebKit Chrome Blink

WebKit絡みの話が続く……

接頭辞のついた実装、レガシーな機能を削除したいときに「それらに依存したコンテンツに影響する」というのが懸念される。こういった理由もあって、WebKitでは接頭辞付きの機能は、接頭辞なしの機能が実装されても基本的に保持されて続けている。

Mozillaは削ることに頑張っていて、-moz-border-radius や -moz-box-shadowを始めけっこう削っている。ただ、消したら影響が思ったより大きくて戻したなんてものもある。Node.hasAttributes() とか、window.mozIndexedDB とか。

この、機能を削ることができない空気や、機能を削ってもバックアウトされてしまうのは、削りたい機能に依存したページがどれくらいあるかを知る手立てがなかったからなのかなと。

FeatureObserver登場

ここにひとつ進展があったのが2012年の9月。GoogleがWebKitに FeatureObserver というものを導入した。

Step 3: There is no step 3. ってのがなんかかっこいい。

Chromeには使用統計データをGoogleに送信するオプションがある。これを利用して、FeatureObserver は登録した機能が使われているページをカウントし、サンプルを取っている。

どんな機能が対象になってるかは、説明するよりファイルを見るのがはやそう（WebKit, Blink）。

成果として、webkitNotifications.createHTMLNotification()が削除されている。もっとあるかと思ったけど、そうでもなかった。
WebKit接頭辞絡みだと webkitPostMessage や先日の -apple-, -khtml- も削除されているけれど、こちらはとりあえず削ってみたというパターンみたい。

BlinkではUseCounterに

Blinkでは新しい機能に接頭辞つけないというポリシーに加えて、既存のレガシーなものについても、ケースバイケースだけれど削除できるならしようという感じで動いている。いまも、Content Security PolicyのWebKit独自ヘッダ X-WebKit-CSP の削除について議論されてて、そこでも FeatureObserver からのデータが挙げられていた。

ただ、“feature observer”といいつつ「機能の監視」をしてるわけではないだろうということから、Blinkでは UseCounter という名前に改められた。WebKitはそのまま。

モバイルでのStatsは？

気になるのは、モバイル。というのも、まだ環境が整ってないように思うから。

デスクトップ版のChromeはStable ChannelにもUsage statsを送信するオプションがあるはずだけれど、モバイル版Chromeには今のところBeta Channelにしかオプションが用意されていない。モバイル版のBeta ChannelはGoogle Playで検索しても出てこないので、インストールベースもデスクトップ版のBeta Channelに比べて少ないだろう。なによりChromeがICS以降に対してしか提供されていないので、こちらはこれから、ということになりそう。

また、ChromeがWebKitを離れたので、「本物」のWebKitに依存する機能をキャッチできなくなってしまう。FeatureObserver は他のportでも使えるように整備されたっぽいんだけど、じゃあAppleがSafariで使うかというと、どうかなあ……

一説によるとモバイルのトラフィックの多くをiOSが占めているらしい。となるとAndroidよりもiOSからアクセスできるページのほうも見とかないといけないのではないか。AndroidとiOSでコードを出し分けている可能性も否定できないので。そこまでな状況になってないといいけど。

あと、モバイルWebではなくて(UI)WebViewを使ったモバイルアプリについても知らないといけないのではないか。これは去年のWebKit contributors meetingでAppleが接頭辞の削除に関してみせた消極的な反応のひとつ。アプリはそこで閉じているぶん、プラットフォームべったりのコード、-webkit-祭りになっててもおかしくない。WebViewにもそういう仕組ができればいいのだろうけれど、どうなんだろうなあ。

さよなら -apple- に -khtml-

WebKit

3月半ばに書いてそのままになってた下書きを発見。
なんで放置してたんだっけ……引用多すぎるからかな。まあいい。

WebKitにこんな変更が加わった。

先日Paulが公開した “WebKit for Developers” （日本語訳）を読んだHacker Newsの読者があることに気がついた。

"CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-."

Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right?

「Chromeでは -apple-, -khtml- が無効にされてる（って書いてある）から、これでChromeとそれ以外のWebKitブラウザを振り分けられるんじゃないか」と。
たいへん賢くていらっしゃる。

これを見たAdam Barthがwebkit-devに共有。

If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix.

I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late.

テクニックとして広まったらどうにもならんと。Chromeで無効にしているけどほとんど問題ないし、他のportでも LEGACY_CSS_VENDOR_PREFIXES を無効にしようと。

これにAppleのDavid Hyatt, Maciej Stachowiakも賛同して、実装に関する議論をちょっと踏まえてパッチがチェックインされましたというお話。

まだ他にもすることがあるようだけれど、これで、たぶん次期バージョンのSafariから -apple-, -khtml- 接頭辞がWebで使えなくなる。Webも感謝するってさ。

さて、これ、息の長いプロジェクトだったりする。始まりは2010年7月、当時まだGooglerでなかったPeter Beverlooがwebkit-devに投げたメールから。

While going through WebCore for some CSS research I'm currently doing, I came across a piece of code[1] which translates all "-khtml-" and "-apple-" vendor-prefixes to "-webkit-". This effectively means "-apple-transform" and "-khtml-transform" can both be used instead of "-webkit-transform". I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix.

My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. [...]

I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped.

当時の実装では、-khtml-, -apple- がついたプロパティが -webkit- の同名プロパティにマップされていたらしい。BeverlooはWebKitの経緯はわかるが、KHTMLとWebKitはもはや別のエンジンなので -khtml- の削除を提案している。

これに対するMaciejの返答は消極的だった。

The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we realized WebKit would not be an Apple-specific project forever, so we switched to -webkit. The main risk to removing the old prefixes is that some older WebKit-specific content authored against them will break. I'm not sure the code cleanup benefits outweigh the risk of breaking content.

If we want to phase out support for these older prefixes, what I'd propose as a first step is supporting the legacy prefixes for old properties but not for any new ones.

もともとWebKitでは -khtml- を使っていて、その後 -apple- を使い出した。ただその後Apple以外の手も加わり始めたので -webkit- になったと。古い接頭辞を削除すると、古いWebKitに依存したコンテンツが壊れてしまうリスクがあるので、クリーンアップがそれに勝る益を得られるかはわからないと。

ただ、BeverlooはWebKitには接頭辞ついたものがただでさえ多いのに、さらにエイリアスもあると3倍になってしまうことを懸念していると返答。そのうえで、-khtml-, -apple- をマップするプロパティを特定の者に限定すればと再提案。

Right now WebKit has by far the most prefixed elements[1], a significant part of which have not been standardized/drafted yet. Keeping the translation for all properties active practically triples the amount of supported vendor-specific CSS extensions, which cannot be desirable. I'm not opposed to the idea of limiting the supported properties for these prefixes to a certain subset, but my preference would be to only support behavioral properties as "-webkit-binding", "-webkit-font-smoothing", "-webkit-highlight" and "-webkit-user-(drag|modify|select)". In the same piece of code, prefixed versions of border-radixes and opacity are still supported as well. Although I think the latter of which could be removed as well, considering Safari 1.1 got released in 2003.

そこへDavid HyattがMaciejの発言を一部訂正する形で登場。

> The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple.

That's not quite right. Originally we just had -khtml- for CSS extensions, and then we used -apple- for features that we were Apple-specific, i.e., that we knew nobody else would care about. Those features include Dashboard regions and Safari RSS line clamping). Eventually we just decided to merge both into a common prefix, but we wanted to keep the old property names working for compatibility. It was convenient to just map both to -webkit- rather than actually checking the specific property names and only supporting either -khtml- or -apple-.

My recommendation would be as follows:

  1. (1) Drop support for -khtml- completely.
  2. (2) Continue to support -apple- for -apple-dashboard-region and -apple-line-clamp only.

-apple- な機能は、DashboardやSafari RSSなどApple固有の機能に使う機能に用いていたけれど、後にそれが -webkit- に一本化したときに互換性のため古いものを残したと。そのときに、どのプロパティかをチェックするよりもエイリアスにしたほうが楽だったとのこと。

で、Hyattは-khtml- の削除と -apple- を -apple-dashboard-region, -apple-line-clampのみに限定しようと提案。

これによりパッチが作られたのだけれど、残念なことにDashboardウィジェットに影響がありすぎたのでダメだった。

それから2年弱経った2012年4月、Adam BarthがDashboardウィジェットにだけ古い接頭辞を有効にするようパッチを携えwebkit-devに登場。

In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes:

https://lists.webkit.org/pipermail/webkit-dev/2010-July/013519.html

At the time, we tried an approach recommended by David Hyatt
<https://lists.webkit.org/pipermail/webkit-dev/2010-July/013536.html>,
but that approach appears to have been too agressive in that it broke a number of Dashboard widgets:

https://bugs.webkit.org/show_bug.cgi?id=42093#c29

Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT):

https://bugs.webkit.org/show_bug.cgi?id=83256

This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web.

I welcome any thoughts the list has on this topic.

互換性について軽く心配する声があったので、AdamはChromeで無効にしてみて問題がないか試してみようと提案。

One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of release blocking bugs.

結果、Chromium portでのみ -khtml-, -apple- が無効にされた。

それから半年近く経った2012年9月、Adamが進捗報告をwebkit-devに。まめだ。Adam何にでも関わってるしほんとすごい。

As discussed in
<http://lists.webkit.org/pipermail/webkit-dev/2012-April/020183.html>,
Chromium experimented with removing the -khtml- and -apple- vendor prefixes from CSS properties. We broke one Apple web page, which Apple was kind enough to fix. Other than that, we have encountered no problems.

曰く、AppleのWebサイト1ページに影響があったものの、それ以外に問題はなかったと。よかったよかった。

ただその後webkit-devでは特になく、先日のメールにて復活、ようやく動いたと。

接頭辞が無効にされるのは時間がかかるねえ。ただ、以前よりは「そんなの無理だ」感はなくなってきている（CSS TTAやGradientsは無理だろうけれど）。調査ができるようになって、それによって削ってもいいだろうという判断基準ができたというのが大きい。あまりにhalf-bakedな機能はビルドフラグやランタイムフラグに隠れていたりもするし、接頭辞問題への取り組みはだいぶ前進したんじゃないだろうか。解決するかは、また別の問題だけれど。

Chromeの新エンジンBlink ― どうなるんだろう篇

Blink WebKit Android Chrome Safari Opera Standards

なぜなに篇とWebプラットフォーム篇ではBlinkに至った背景や、Blinkの互換性への取り組みについてだーっと書いた。
今回はBlinkの登場が何にどんな影響を与えるか、だらだら考えてみる。

Chrome

すでに色々書いてはいるけれど。

WebKitから離れ、Chrome専用エンジンとなるので、これまでWebKitでは合意を得られなかった機能について抵抗なく入れられるのはGoogleにとってはよいことだろう。Pointer EventsとかIME APIとか。Launch Processのもとでだけど、試験実装は進めやすくなる。

WebKitから離れることでの最大の損失は、WebKitに参加している人のタレントだろう。BlinkチームのQ&Aセッションによると、BlinkとWebKitとの間に「フォーマルな関係」はないとのこと。パッチを自動的にやりとりするような仕組みは用意されないから、コントリビュータがボランティアで、パッチをどちらにも投げる、あるいはマージするしかない。BlinkとWebKitが離れていくにつれて難しくなっていく。

あとは、これまでWebKitにあったバグはBlinkにも引き継がれるわけだけど、WebKit BugzillaからChromium issuesに自動インポートするとかそういうのもない。誰かがそれをしないといけない。やんないとなあ。面倒だよねえ……

(追記: Syoichiさんに一部バグ移行をしてる方がいると教えてもらった。)

Opera

OperaがWebKitに移行した時に、WebKitプロジェクト内でどうOperaのユニークネスを活かせるのか、不安を交え書いた。ただ、Blinkに移行したことで政治に関わるプレーヤーが減った、というか決定者に近い立場になった。

Launch Processにある、標準へのコミットやテストへの言及はOperaがこれまでWebに大きく貢献してきたことだ（標準化については、関わってたひとが結構辞めちゃってる印象があるけど……）。BlinkになってOperaはとてもよかったのではないか。

AndroidとWebView

AndroidのWebViewもChromiumベースになっていくので、Blinkがそのうち入ることになる。よりよい設計のものがもたらされるはずなので、よいことなんだろう。

アップデートやフラグメンテーションについては、わからない。たまに家電量販店に行って新しい端末を見るんだけど、Androidのバージョンは4.1だし、Chromeの他にもAndroidブラウザが入っちゃってたりするし、Web開発者にとっては好ましい状況ではまだない。

WebViewに手が入ってしまう問題は解決するのか。なってほしいけど、エンジンが変わったくらいで変わる問題じゃなさそうな気がする。Android 5.0の発表が噂されているけど、WebViewまわりはどうなるのだろう。

あと、WebViewのバージョンはChromeのように6週間でバージョンアップ、なんてしないだろうし、できないだろう。Webなら「これからChromeになるんで〜」とそのうち言えるようになるんだろうけれど、WebViewを使ったハイブリッドアプリとかだと、苦しい状況が続くのかもしれない。

強制的なアップグレード機能をもつChromeの下にAndroidが入ることで、アップデートについて改善したりするといいんだけど。

WebKit

やっぱり気になるのが、WebKitプロジェクトへの影響だ。

BlinkがChromiumに必要ないコードを削除している一方で、WebKitもChromium関連のコードやV8バインディングを削除している。メンテナがいない機能もまとめている。こういうのが削除されて行くと「違うエンジン」になるのは案外早いのかもしれない。

WebKitに集っている他のパーティはどうなるんだろう。GoogleがいたからWebKitを選択したっていうのがひとつの理由だったパーティも少なくないのかなと思う。でも、BlinkはChromiumのContent API上での利用しか検討していない。使うのであればと、Chromium Embedded Frameworkが提示されているけれど、すぽっとWebKit→Blinkに移行ってのはできるんだろうか。

加藤さんが言っている、WebKit発のイノベーションが消えないか、主要スポンサーが一つ失われたOSSプロジェクトはどうなるのかというところも気になる。

WebKitが終わりだ、とは思わないんだけれど、WebKitであることの大変さは、Blinkの登場によって今まで以上に表面化してしまった。ほんと、今後どうなるんだろう。

テキスト選択のハイライト範囲が気持ち悪いのと、いろいろあるバグを除いて、WebKitは好きなので、今後も発展し続けてほしい。

Adobe

注目したいのが、Adobe。

AdobeのWebプラットフォームへの貢献は、ブラウザベンダーではないという彼らの業態もあってユニークだ。WebKitにはRegions, Exclusionsなどレイアウト機能についてパッチを提供してきた。ほかにも、MaskingやCompositing、Custom Filtersなど、画像合成・変形にも多くのリソースを提供している。

彼らが貢献していく領域は、Adobe & the Webというページに書かれている。“Robust graphical foundation”, “Magazine-like layout”, “Cinematic visual effects”, “Typography”, “Consistency”, “App platform”とあるけれど、とくに最初の4つはAdobeの強みがはっきりわかるのではないだろうか。

WebKitに貢献している理由は書かれてないけど、おそらくiBooks登場→EPUB使う→CSSへぼい→InDesign使うパブリッシャーから要望→WebKitに手を入れるしか、的な流れなんだと思う。

なので、今後も基本はMac port, つまりWebKitがプライマリなターゲットなのかなとは思う。ただ、人材募集を見るとWebKitだけでなくGeckoにも詳しい人を探しているし、実際Geckoにもパッチ提供したりしてるし。Blinkについても、Blendingについてのパッチ投げるよ的なことも言ってるので、特定の領域にはAdobeが絡んできそう。彼らの提案する機能はWebから見ると「新しい」ので、成熟させてWebで使えるようになってほしい。

あと、BracketsなどはCEFを使っているので、そっちからBlink/Chromiumへのコミットもあるかもしれない。もうあったりするんだろうか。

Apple

気になるというか懸念してるのが、roc先生も書いてるけど、SafariというかAppleが今後閉じてしまわないかということ。

AppleがWebKitに果たした影響はもちろん大きい。立ち上げたというのももちろん、CSSへのグラデーションやマスク、変形、アニメーションなど、Appleがむりくり導入したから可能性が広がったってのもあると思う（そうじゃなかったら未だにSMILやSVGとか言って、あまり進んでなかったかもしれない）。

ただ、Appleが導入した機能って、設計がまずいといわれることが多々ある。古くはCanvas API、もうちょっと新しいのが<meta name="viewport">とか。あと -webkit-gradient() も評判が良くなかった記憶がある（これは構文変えまくったりとか、標準トラックでの設計もまずかったけど……）。標準化への進みが遅れると、いけてない機能から何年も移行できなくなる。viewportとか、いつCSS側にもってこれるんだろう……

新しい機能の追加は、webkit-devにメールを投げてラフな合意のもと実装というプロセスが2年前くらいから運用が始まっていた。標準に入っていない機能が提案されると「WGに投げとき」てきな返答が返ってくるとか、よい流れになってきたんだけど、そこからGoogleがいなくなる。このプロセスは、今後も維持されるのか。

独自拡張が悪だとはそんな言いたくないけれど、Appleの独自拡張はモバイルでの影響が無視できない。その後標準化が始まったとしても、他での実装やSafariの挙動の修正には時間がかかる。

Appleは今後どれくらい、標準化にリソースを割いてくれるのか。今と同じ、もしくはそれ以上でいてくれるのか。

標準化・Webプラットフォーム

新しいエンジンとはいえ、現段階では「ほとんどWebKit」なので、標準化にあたっての「2つの独立した実装」という要件にBlinkがカウントできるかというと、現時点では無理だろう。Prestoの抜けた穴はすぐには埋まらない。

ただ、今後Blink, WebKit双方に追加されていく機能については、コードが独立する可能性があるので、そうなれば独立した実装と認められるだろう。既存機能については、そこにタッチする何かで大規模なリファクタリングや書き直しが行われたりしないと、WebKitとしてカウントされるんじゃないかなあ。

Webプラットフォームとしてみると、GoogleのリソースとAppleのリソースが離れるので、機能の進みが「鈍化」したと感じるのかもしれない。

Launch Processで明文化された、標準へのコミット。Chromium Feature Dashboardを見ると、けっこう色んな所でベンダー間の思惑に違いがあることがわかる。Webは進んでくれるのか。Blinkプロジェクトは、彼らのプライオリティとしてあまり高くないものについての標準化に、どれくらい貢献してくれるのか。

しかし、他のベンダーの反応が視覚化されると、スタンスがいろいろあるのだなあ、みんなせーので同じものとはいかないのだなあ、と、すこし憂う。良く言えば多様で、よいことなのだけれど、「これが今使えたらなあ」と思うものがちらほらとあるので。

Web開発

Web開発に変化が起こるか。短期的にはもちろんだけど、中期的にも変化が起こるかというと、そんなないと思ってしまう。憂う。

下を見てしまいがちなんだ。デスクトップならIE8（以下）、モバイルならAndroidブラウザ、そこを最低ラインとして作り方を考えてしまう。

モバイルについては、Androidブラウザ＋Safari＋(UI)WebViewというWebKit寡占状態がしばらく変わりそうにない。Chromeががんばっても、Blinkがしばらくは「ほとんどWebKit」だし、WebKit依存なコードが減るのかというと、そんな気はあまりしない。減ってほしいけど、ずっとゆっくりなのかなとも思う。

モバイルに非WebKitなブラウザが増えるか。どうなんだろう。Firefoxが起こせたようなことが、モバイルでも起こるといいなあとは思うけど、ただでさえダイバーシティが少ないので……

標準においても、UI関連イベントやスクロールとか、追いついてない部分が多い。WebKit依存や開発者への訴えかけで問題が解決するわけでもない。これを「発展の余地がある」と捉え続けられるのか。

ぼく

Blink関連の情報を読んで、Blinkにはとてもポジティブな見方をしている。ひねくれているので、まあ今とそんなに変わんないなとも思うし、プロセスの「例外」が増えることへの危惧は否定できない。けれど、WebKitでなくなったことの利点って、

Blinkで驚きだったのが「こういうことになりまして、これです」という事後発表ではなく、「こうします」という発表だったこと。準備はしていたんだろうけど、MLやレポジトリ、他のいろいろも発表後から始めている。スタートのアピールとして、とても上手いなと思った。

このアピールは何なのだろうかと考えて、Blinkはコミュニティを欲しているのかもしれない、と思った。やはりWebKitのエンジニアを失うのは痛いし、これからは自立してかないといけない。Chromium/Blinkに貢献してくれる人、ほしいのかなあと。「コミュニティ」感が出ると、言ってることの「いい子ちゃん」感も薄れるだろうし。そういう点でMozillaってやっぱ「コミュニティ」としてとても強い気がする。

1週間立ち、要らないコードががーっと削られている。DevToolsは変更が入り始めた。ディスカッションでは、今後どうして行こうかという話が進んでいる。「いま起こっていることとして感じられて」わくわくがある。今まで「『スピード感』て何よ、とくに『感』って」と思ってたのだけど、これがそういうことなのかなあと思った。

標準/ブラウザウォッチャーとしては、WebKit依存でWebが終わる感じが少し薄れたのでよいと思うし、対象が増えて素敵。一方で、対象が増えて、しかも開発スピード上がるとか言うんで、しんどそうとも思う。Peter BeverlooもBlinkウォッチャーになるので、WebKitは有用なソースも減ってしまうし。ウォッチャーとしてはチャンス（なんの）でもあるけれど。

いま気になってるのは、ChromiumとBlinkのレポジトリ統合が提案されて、それが支持されてる感じなこと。開発としてはよいのだろうけど、これされると、Chromiumレポジトリを追いかけないといけなくて、Blinkだけの変更が追いかけづらくなってしまう気がするんだよなあ……。何かいい方法とツールを探したり、場合によっては作ったりしないと……

ただ、いまのやり方はだいぶ非生産的なかたちをとってるので、もうちょい良くしてかないといけない。あと、いつまでもウォッチャーのままでなく、もう少しブラウザやら標準にコミットしないとね。自分にできること見つけないと。そういう点でChromium Feature Dashboardができたのはとても嬉しい。ちょっと突っ込んで参加してみようと思う。

感想なのでだいぶ雑になってしまった。MicrosoftやMozillaについては思いつくことがなかった。Dartについては詳しく知らないので何も書けず。

これにてBlinkについてのエントリはひとまず終了。引き続きウォッチ的なエントリとかを書くよ。

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

Blink Chrome Standards

よいサブタイトルが思いつかなかった。
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 SeidelとAdam 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やその開発についての説明はここまで…と思いたい。
ただまだ、今後なににどんな影響をあたえるのか考えたものを書いてないので、次回はそれを。もうちょっとだけ続くのだよ……

Chromeの新エンジンBlink ― なぜなに篇

Chrome Blink WebKit

4月3日、GoogleがChromeに使っていたWebKitをフォークした新しいエンジンBlinkを発表した。

…だいぶ出遅れたのでとても書きづらいけれど、自分の理解のために書く。ただいろいろあるので、まずはWebKitをフォークするに至った経緯と、Blinkの概要について。

追記 (2013-04-30)：別途ふたつエントリを書いたのでそちらもどうぞ。

“Chromium port”としての負担

アナウンスしたAdam Barth曰く、Chrome開発時点でのWebKit採用は正しく、WebKitも大きく成長したと。

ただ、開発を続けるにあたり、アーキテクチャの違いなどからChrome, WebKit双方に負担がかかる状態になった。これを解決するため、WebKitをフォークしたエンジンBlinkに移行するとのこと。

Blinkのドキュメンテーション、GooglerがBlinkについて書いたポストからも、WebKitを使うことで生まれた解決しづらい問題、メンテナンスの負担がうかがえる。

Justin Schuhは、Chromeの設計が他のWebKitブラウザと違っており、WebKit2へのシフトでさらに違いが強まったと書いている。たとえば、セキュリティを向上させる重要な機能を追加したかったけれど、WebKitにフィットしないため見送ったことがあるとか。また、異なる開発スケジュールからくるリグレッションへの対処、古いWebKit APIが必要としていた挙動の管理など、維持にも問題があったようだ。

Philip Rogersの、WebKitはSkiaだけではなくCoreGraphics, Cairo, etc.など主要5つのグラフィックライブラリ上で動作しなければいけないという話からもつらそうなことがわかる。なにか機能を実装しようとしても、実装に必要な機能がどれかひとつのグラフィックライブラリにでも欠けていたら、その機能を実装できない。ひいては仕様策定にも影響したとあるので、Webにとってもヘルシーな状態ではない。

Alex Russellは、WebKitのいちportとして開発していくことの負担について、抽象度合いが低めのレベルなWebKitではあるportが他のportに影響を及ぼしてしまうため、portが増えるたびにコストが上がっていたと述べている。また、エントリのはじめのほうでこうも言っている。

What’s bound to be missing in most of this coverage is what’s plainly said, if not in so many words, in the official blog post: going faster matters.

Not (just) code execution, but cycle times

Chromeの掲げる「速さ」は、コード実行速度だけではなく、開発サイクルにおいても重要だと。

Blinkになるとどうなるか

BlinkはChromiumのContentモジュール上に作られる抽象プラットフォームに依存するような設計になるとのこと。Contentモジュールは、マルチプロセス・サンドボックスな環境でページをレンダリングする際に必要な、コアなコードを束ねたモジュールだそう（うう、よくわかんない…）。
この設計によって、機能や変更を加える際に対応するプラットフォームがひとつになり、他のportが使うライブラリやレガシーなWebKit APIへの依存がなくなると。なお、Content APIとWebKitやWebKit2, WebCoreなどがどう違うかは、Ben Goodgerのポストで取り上げられている。

Blinkの開発について。短期的には、Chromiumに必要ないWebKitのコードや、Chromium以外で使われていたビルドシステム7つ（！）を削除し、内部アーキテクチャの向上や、コードベースの単純化を行うとのこと。コミットログやコードレビューの一覧を見ているのだけれど、コードの削除がガンガン行われている。新しい機能の追加についてもblink-devで既にいくつか提案されているけれど、コードの進みはなさげなので、Web開発における影響は今のところないだろう。

中長期的には、WebKitを使う都合上でできなかった設計変更が視野に入っているので、話は変わる。WebKitによる制約が取り払われることから、多くのアイデアが出ている。

たとえば、DOMの処理をJavaScriptの処理に移動させるというのがある。これまでJavaScriptからDOMにアクセスする際はJavaScriptのVMからコードがでなければならず、（それでも十分速いんだけど）コストがかかっていた。JavaScriptが直接アクセスし、VM内で処理を完結できるようにすることで、速くできるとか。

こういう大きな設計変更が入ってくると、KHTMLとWebKitがもはや別のエンジンと考えられているのと同じように、BlinkもWebKitと違うエンジンとなるんだろう。いつ頃になるのかはわからない。何を持って「違う」と考えるかにもよりそうだけど。

BlinkはいつChromeに入るのか

もう発表当日のCanaryに入って、Dev Channelにも反映された。

SVNのログを見ると、Blinkがrollされたのが分かる。

というわけで、Chromeは28からBlinkに移行する。ChromiumベースのものはBlinkに移るので、OperaもBlinkになるとOperaのBruce Lawsonから発表があった。発表当日にあったQ&Aセッションでは、Chromiumを使うように進んでいるAndroidのWebViewもBlinkになっていくことが話されていた。メモしといたので、参考までに。

あ、ただ、Chrome for iOSについては話が別で、こちらはUIWebViewをつかった今までのもの（WebKit）と変わらない。どうしようもないものね。

ううむ。これくらいは金曜くらいまでには書いておきたかったなあ……。

次はBlinkの機能追加ポリシーについて書く。その後はBlinkによってほかのプレーヤーにどんな影響があるかを考えてようかと。

リークしたIE11の情報からいろいろ邪推する

Microsoft IE

Windows Blueのビルドがリークしたらしく、それに搭載されるIE11の情報がちょこちょこと出始めている。

UA文字列が変わるらしい

UA文字列を大幅に変えてくるらしい。

リークしたWindows Blueのビルドに搭載されたIE11のUA文字列が、こうなってたと。

Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

IE10のUA文字列はWindowsのバージョンやタッチインターフェースの有無によって違うけど、ベーシックなのはこう。

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

比べると、compatibleやMSIE など、これまでIEにあったトークンが消えて、IEとlike Geckoという別のものが入っている。

Neowinは「Firefoxと見せかけてる」と書いてるんだけど、like GeckoはAppleがSafariのUA文字列に入れた(KHTML, like Gecko)というものの一部なので、この場合どちらかというとWebKitに見せかけているのではないかね。ここらへんNeowin残念。

ただ、よく見るとrv:11.0というのもある。このrv:はGecko特有のもの。なので、実はFirefoxにも見せかけてもいたりする。結果的にあってる……！なんか悔しいな。

意図は「IEに非ず」だけど……

意図としては、古いIEとして判断されないようにしたいんだろう。ただ、IEとして判断されないようにするんだったら、compatible廃止やIEへの変更で十分だと思うかもしれない。どうしてGecko, WebKitに見せかけるトークンを入れたのだろう。

たぶん、何かしら既存ブラウザのUA文字列と互換性がないと、困ってしまうんだろう。MSIEやGecko+rv、それにlike Gecko/AppleWebKitなどに引っかからなかったら「推奨ブラウザじゃないです」的なページに飛ばされるサイトなんかが、まだかなりの数あるんだろう。

この、既存ブラウザのUA文字列との互換性確保はいまに始まったことじゃない。IEがMozilla n.0を、Safariがそれに加えてGeckoを含んだりしたのも、そういう理由から。ここらへんは、Nicholas C. Zakasが以前UA文字列の歴史について書いたポストが詳しい。IE11のUA文字列についてのポストでも、同じようなことを言っている。

機能の互換性も確保してくるだろう

さてさて、「互換性」と書いたけれど、UA文字列にGecko, WebKitとして判断されうるトークンを入れた結果、Gecko/WebKit向けのコードが提供されうることから、非互換を生み出す可能性だってある。なので、UA文字列だけではなく、機能についても他のブラウザと互換性をとらないといけない。IE11ではどういうことをしてくるのか。

ひとつは、ベンダー固有プロパティを標準で定義してもらう、もしくは標準を既存サイト・ブラウザの挙動にあわせて修正してもらって、それを実装する。HTML5やDOM4などがずっとやってきたことなのでとくに新しくはないけど、そういう動きは実際にやっているっぽい。

先日、HTMLに navigator.product というプロパティが定義された。定義上はただ "Gecko" という文字列を返すひどいプロパティなんだけど、バグを投げたMicrosoftのTravis Leitheadによると互換性のために必要らしい。Chrome, Firefoxでも実装されてて、IEでも追加するので仕様に取り込んでくれと。

固定値から予想するにMozilla由来だろうけど、こんなプロパティに依存するサイトもあるんだね……。

-webkit- 対応も？

さて、Travisはバグの最初でこんなことを言っている。

As we continue to improve IE's engine such that it runs more of the non-IE based web, we've seen that it is now necessary to support the navigator.product attribute. It should simply return "Gecko".

This behavior is already present in Chrome and Firefox, and IE will be adding it soon.

Consider this for HTML5 as well to codify this behavior for interoperability and actual site compatibility.

「IEベースではないWebが動くように」と言っている。このIEベースでないWebってなんだろう。なんだかんだで大きなシェアを持ってるWebで、IEを無視するようなものってそんなに多くないだろう。

ひとつは、まだ実装してない機能を使ったサイト。これは（試験）実装をすればいい。リークしたIE11の機能を読むと、WebGLの実装が予想されている。__proto__ もあるらしいけど、これはES6に入るので、（先行）実装すればよい。

もうひとつは、モバイルWebだろう。特にWebKit接頭辞やWebKit固有の機能に依存しているページが多いだろうし、どう考えてもIEベースではない。

となると、それらへの対応、もしかしたら -webkit- の実装があるかもしれない。Operaは12.1で一部の機能をエイリアスさせている。Micorosoftも、Windowd Phone 7のベータ時代にIE Mobileが -webkit-text-adjust を解釈するよと発表して反感を買ったりしたこともある（その後撤回した）。Operaは結局斜め上な「WebKit対応」をとったけど、IEが今度こそ正攻法（！？）なWebKit対応をしてきてもおかしくないかなと。

とはいえ、feature detection を薦めたり、さんざん “Same Markup™” と言っといて “Same Markup (to WebKit)” というのは違うだろう。なので、やるのであれば前にも書いたことがあるけれど、Compatibility Viewリストに登録したサイトだけで動作させるようにするんじゃないか。

まず、互換性のために必要な固有機能、たとえば -webkit-mask を標準に即したかたちで実装する（もう標準に取り込まれたけど）。その上で、WebKitへのマッピングを行うCompatibility Viewのディレクティブを設け、WebKit依存なサイトを見つけ次第CVリストに登録する。こんな感じだろうか。

CVリストのデータを見ると、X-UA-Compatible からは設定不可能なディレクティブやパスの指定、GPUに関するなんかの指定が大量にある。もはやこんな状態なので、ここにWebKitなんとか的なものが入っても不思議ではないかなと。

ただ、MozillaがFirefoxでした調査によると、プロパティのエイリアスやUA判定だけでは互換性がそこまで向上しなかったって話もある。IEの場合はわからないけれど、どうなるんだろう。

こんなところ。WebKit対応があるかは結構大きく予想してみた感じだけど、どうなるかな。

余談：navigator.product の経緯

「Mozilla由来だろう」と軽く書いたのだけれど、productという名前でGeckoに値が固定されていたのが気になったので調べてみた。

まず、WebKitの実装について。ChromeというよりWebKitでの実装だと思ったので調べたらなんと2002年に追加されていた。その時から値は "Gecko" で固定されていたようだ。関連バグがないので経緯は不明だけど、まあ互換性のためなのかなと。

で、Mozillaはソースを追えず結局いつ追加されたのかわからなかった。ただ、以前はちゃんとプロダクト名を返していたようだ。それがハードコードされたらしい。関連バグBug 776376によると、WebKitが単に "Gecko" を返すのでそれにあわせたらしい。ふむー、へんな経緯。

追記 (2013-04-30)

Mozillaにnavigator.productが入ったのは2000年3月21日とのこと。ありがとうございます。なるほど、Bonsaiを探せばなんとかなったのか……

Meaningless ― Web semanticsの観測

HTML Chrome

W3CのTAGメンバーにもなったGoogleのAlex Russelが、Webサイトで使われている要素、ARIA roles/states, microformats, schema.orgの型などを調べてまとめるためのChrome拡張をつくった。

HTMLの議論などで、要素の意味などに関する議論は絶えない。「〇〇が足りない」とかね。ただ、だれも充分なデータを持っていない。というわけで作ったそう。

集まったデータは http://meaningless-stats.appspot.com/global で見られる。上位の要素にcode, varがあったりと、まだだいぶ偏っている感じだけど……（たぶん仕様書にアクセスしまくってるんだろうな……）

こういう観測はGoogleが2005年にやった計測結果や、OperaのMAMAなどもあるけれど、それから時間は経っている。「いま」を知るためには、多くの人がMeaninglessをインストールして、いろんなサイトを見ることが必要。Alexはインストールを広く呼びかけているので、協力できる人はしよう。

今のところChromeだけなので、他のブラウザ対応とかもほしいところ。UA判別で観測対象のマークアップが変わるとか、なくもないからね。

モバイル系ブラウザのUA文字列

Chrome Mozilla Opera Android Safari IE

何の役に立つか自分でもさっぱりわからないと思いながら、ここ1年半ほどGoogle Spreadsheetsにブラウザのアップデート情報を記録している。

できるだけ情報を入れてるけど、抜けも結構ある。ChromeはStable Channelが入ったマシンがないので細かい情報はないし、Firefox ESRとかは要らんだろうと思って入れてない。

さて、もともとデスクトップだけだったんだけど、最近Chrome for AndroidとOpera Beta（Chromiumベース）が出たので追加し始めた。Opera Betaには chrome://versionみたいなのがなくてしんどい……

それで、UA文字列にバリエーションがけっこうあって複雑だなあと思ったので、ちょっと書いてく。

スマートフォンとタブレット

まず、スマートフォンとタブレットでUA文字列が少し違う。

Chrome for Android, Firefox for Android

Android版Chromeだと、スマートフォンにはMobileというトークンが入る。タブレットでは取れる。

Android版Firefoxだと、スマートフォンにMobile, タブレットにはTabletというトークンが入る。ネットブック的なAndroid端末（あるんだ）だとトークンがなくなるらしい。

iPhone, iPad

iOSのSafariだとプラットフォームトークンがそれぞれiPhone,iPad,iPodになる。

Mobileというのもあるけれど、こちらはどのSafariにもあって、文字列の後にMobile/XXXXXと、ビルド番号がついている。タブレットとモバイルを区別するものとして設けられているわけではない。

Windows Phone 8, Windows 8/RT

IE10は、Windows Phone 8とWindows 8/RTとOSが違うけど、UA文字列の構成はそんなに変わらない。Windows Phone 8のIE10ではIEMobileがつく。あと、Windows Phoneってプラットフォームトークンもある。

一方タブレットなんだけれど、Windows 8/RTのIE10ではタブレットとデスクトップを区別するトークンがUA文字列にない。Windows 8世代の製品はデスクトップでもタブレットでもタッチインターフェースを備えるから、区別っていう概念がないんだろう。

ただ、タッチインターフェースを備えている場合、Touchというトークンがつく。これはWindows Phone 8でもつく。ただ、タッチを備えていてもWindows 7のIE10にはつかない。

「デスクトップ版」のUA

これで終わりかとおもいきや、もう一つ種類がある。「デスクトップ版」のUA文字列というもの。モバイルなのになんだそれ。まあデスクトップセントリックなサイトが多すすぎる一方でしょうもないスマートフォン版のサイトも多いんだろうけれども……

Chrome, Firefox

Android版Chrome, Firefoxには “Request Desktop Site” なんてメニュー項目がある。これを選択すると、UA文字列がデスクトップのものになる。

Nexus 7でChrome BetaとAuroraのUA文字列をそれぞれチェックしてみた。まずはChrome Beta。

// Default
Mozilla/5.0 (Linux; Android 4.2.2; Nexus 7 Build/JDQ39) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.40 Safari/537.31

// "Desktop"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.40 Safari/537.31

続いてAurora。

// Default
Mozilla/5.0 (Android; Tablet; rv:21.0) Gecko/21.0 Firefox/21.0

// "Desktop"
Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0

Opera Beta

Opera Betaでは設定からMobile/Desktopを選べるようになっている。これグローバルに変わるんだよね、ちょっと面倒だと思うけど……
UAはこちら。

// Default
Mozilla/5.0 (Linux; Android 4.2.2; Nexus 7 Build/JDQ39) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.123 Safari/537.22 OPR/14.0.1025.53463

// "Desktop"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.123 Safari/537.22 OPR/14.0.1025.53463

結構すっきりしていたOperaのUAがChromiumベースになったせいでだいぶカオスに……
あとOperaの識別子がOPRになっている。これまでのOperaと区別するせいかな。

どうでもいいけど、「Chrome/Chromium/WebKitベースのOpera」とか「新しいOpera」とか長いので、CrOperaもしくはCrOpと読んでいる。くろぺら、くろっぷ。

ええっと、共通して言えるのは、どれもLinux版のUAになる。まあAndroidだから、そうか。

Opera Beta (Off-Road mode)

さて、Opera BetaはさらにもうひとつUAが文字列がある。Opera Betaにある “Off-Road mode” を選択すると、Opera Miniのレンダリングに切り替わるので、それでUAが変わる。

Opera/9.80 (Android; Opera Mini/14.0.1025/29.3054; U; en) Presto/2.8.119 Version/11.1010

バージョンは14になったけど、UA文字列はほとんどOpera Miniと同じ。

Opera/9.80 (Android; Opera Mini/7.5.32193/29.3054; U; en)
Presto/2.8.119 Version/11.10

これを見るにPrestoベースのままだけど、WebKitベースのものに置き換わるという話があるので、このモードのUA文字列もじきに変わるのかな。

番外編：Firefox OS

ちなみに、Firefox OSは今のところえらくすっきりしている。

Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

タブレットの展開は発表されてないけれど、もし出たらMobileがTabletになるのかな。

ただ、ちょっとそれも怪しい。というのもUA文字列でスマートフォンの検出をするときにはiPhoneとかAndroid+Mobileで引っ掛けているので、これだとFirefox OSではスマートフォン版Webサイトに飛ばない。

実はもともとAndroidを含んでいたんだけど、Android端末固有のメッセージを出すためにこのトークンが使われていたりしていて、それではFirefox OSで困るので Androidを外す決定がされていた。ただサイト互換性的なところが多いので、いま頑張ってエヴァンジェライズしてるところらしい。入れないと困るけど、入れても困ると。

いやはやカオスだ。とはいえFeature Detectionだけではというケースも往々にしてあるし、サイトのエミュレーションをする時はUA文字列判定のほうが楽なこともあったりするので、UA文字列に頼るなともいいづらい。面倒だなあ。

あんまそういうのに拘らないサイト、拘らない空気作りをしていきたいよ。

Firefox Nightly (22) に ES6のArrow Function来たる

Mozilla JavaScript

そもそもES6に入ってるのも知らなかったので、2日前にmozilla-inboundにチェックインされててだいぶ驚いた。

で、Nightlyに入るのを待つこと2日弱、ようやく入ったので試してみた。

f:id:myakura:20130321004230p:plain

おお動く。そしてこのJavaScript書いてない感がすごい。

thisがレキシカルにboundされるようなのでイベントリスナとかで楽そうだー。

追記 (2013-03-21)

こんなのよりもっとずっと詳しく丁寧な解説が公開されたのでそちらをどうぞ！