リークしたIE11の情報からいろいろ邪推する
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を探せばなんとかなったのか……
