[9] Web 互換性とは、現実の Web の世界との (主に Webサイトの HTML や JavaScript と、 あるいは Web鯖の挙動との) 互換性のことをいいます。 多くの場合、何らかの仕様書に明示されていない Webブラウザーの挙動について、 それに依存しているものが存在することをもって「Web互換性のために必要」 などと議論する時に使います。
[1] Web で利用されている技術は、広く利用されているため、その拡張や変更には色々な制限があります。 ある実装方法や拡張案を採用することによって現実に存在している文書やアプリケーションの動作に支障が出たり、 意図しない解釈をしてしまったりする場合があります。そういったものをWeb互換でないといいます。
[2] 例えば、 Web 上の相当数の HTML文書は、 タグの入れ子関係が間違っているなど構文上の誤りを含んでいます。 構文的に正しくない HTML文書に遭遇した時に処理を停止し、エラーを表示するような実装は、 Web互換とは言えません。
[10] Webブラウザーおよび近代的なWeb標準の開発において、Web互換性は最も重要な性質の一つであると考えられています。 セキュリティ上必要な場合など極めて例外的な場合を除き、Web互換性の無い変更や新機能は Webブラウザーに実装されることはありませんし、Web互換性のために必要な機能が削除されることもありません。
[3] Web互換でない変更が企てられたことは過去に何例かありますが、 多くは失敗しています。
DOMStringList の廃止click イベントの副作用の廃止CDATASection の廃止createElement の名前空間URLの扱いxml-stylesheet の無視open (XHR) の URL の UTF-8 固定[4] セキュリティーを目的とした変更は Web互換でなくても受け入れざるを得ないことがあります。 圧倒的なシェアを背景に強行される例もあります。
SecureContext 限定keygen の廃止beforeunload の文面無視image-orientation[26] Flash は、Web 上で広く使われており本来なら Web互換性のために実装しなければならないはずですが、 スマートフォンやタブレットの Webブラウザーからは排除されました。 一方でデスクトップブラウザーでは、他のプラグインが排除された後も、 Flash だけWeb互換性のために例外的に実装され続けています。
[35] 日本では MacJapanese も使われていましたが、今の Webブラウザーは表示できなくなっています。 今でも稀に遭遇することがありますが、文字化けしてしまいます。
[18] Web互換性は時代により変化します。ある機能が広く実装され利用されるようになると、 Web互換のために必要な機能に含まれるようになります。逆にある機能が利用されなくなり、 かつて利用されていた時代のWebサイトが機能しなくなったとしても構わないと思われる場合には、 Web互換のために必要な機能から外れます。
[19] ある時代にはWeb互換性のために必要だった(かもしれない)ものの、 その後必要でなくなり(ということにされ)削除された機能には次のものがあります。
[20] また次の機能はもはやWeb互換性のために不要として削除することが提案されています。
multipart/x-mixed-replaceftp: fetch[21] ただ、一度複数の Webブラウザーで実装され広まった機能を削除するのは容易ではありません。
例えば現在ではフレーム (frameset) を使うことはほとんどありませんが、
かつてフレームを使って作られたページが大量に存在し、それらを閲覧できなくなるのは好ましくないため、
削除されていません。
[17] 次の非互換変更が提案されていますが、実施されるか、 されるとしていつになるかは不透明です。
[12] Web互換性は、 Web が vendor 中立であり、 複数の相互運用性の高い実装が共存していることを前提に成立しています。 Webブラウザーは複数存在し、それぞれが (大部分で重なりつつも) 異なる Web 技術を実装ています。著者はその差異を認識し、いずれの Webブラウザーでも意図通りに動作させられる範囲内で Web 技術を用いることを (幸か不幸か) 要求されています。
[13] いずれかの Webブラウザーでしか実装されていない機能や、 Webブラウザー同士で異なる方法で実装されている機能を用いたとすると、 すべての Webブラウザーで正しく動作する文書 (Webアプリケーション) とはなりません。 その場合、仮に特定の Webブラウザーでのみ正しく動作していたとしても、 Web 全体として見た時その文書ははじめから「壊れて」います。 その Webブラウザーが以後の版でその機能の実装方法を変更したり、 機能自体を削除したりして、その文書がその Webブラウザーでさえ正しく動作しなくなったとしても、 元から「壊れて」いたものがより壊れただけです。 相互運用性の低い機能の変更や削除は、 Web非互換とは考えられていません。
[14] 例えば Google は Chrome で Web Intents を実装しました。 いくつかの Webアプリケーションはこれを利用しました。その後 Chrome は Web Intents を削除し、そのような Webアプリケーションは動作しなくなりました。 しかしこれは Web非互換な変更とは考えられていません。
[22] Web の技術を用いているものの、特定の分野の要求に基づき独自のアレンジを加えて利用している環境 (いわゆる walled garden) では、Web非互換な独自の機能が実装されている (されていた) ことがあります。
[23] 次のような例があります。
[24] こうした非互換な機能は、最初は良くても、あるいは当該環境の提供者には都合が良くとも、 次第に Web との一体性が高まって不都合が生じたり、 Web と独自環境で2種類の実装を維持することが (環境の提供者にとってもその環境へのコンテンツの提供者にとっても) 負担になったりして不具合の温床になったり、 やがてメンテナンスされなくなって放棄されたりする一因になることがよくあります。
[29] Web互換性の議論では、ブラウザー拡張やアプリ内ブラウザーを含め、 Webプラットフォームに属さない分野の個別の事情は原則として考慮されません (具体例 >>20)。 そうした独自のプラットフォームでの互換性の維持は、 Web標準開発全体の責務ではなく、当該プラットフォームの提供者の責務と考えられます。
[30] 現実には、 Web の技術の特定の実装の挙動がその実装を使ったプラットフォームではよく使われて、 Web 全体では使われていない、ということがしばしば起こります。 当該プラットフォームの提供者は、 (元々単一であった技術を) Web とそれ以外とで別の動作モードに分けて互換性を維持するか、 独自プラットフォームの挙動を非互換に変更するかといった選択を迫られることになります。
[31] Dashboardウィジェットでは <script />
が空要素として解釈されることになっていました。
標準の HTML構文解析器ではそのような挙動は認められていませんが、
既存のDashboardウィジェットとの互換性を保つため、
標準とは異なる構文解析モードが必要となりました。
これは有名な事例で、 HTML Standard の編集者らも当然承知していましたが、 そのような挙動を標準の HTML に取り込むと Web 側で互換性の問題が生じるため、 どれだけ影響を受けるDashboardウィジェットが多いとはいっても、 HTML構文解析器の動作の規定の根拠にはされませんでした。
[6] 元々 Web互換性はWebブラウザー開発者と仕様開発者の経験や出荷後の不具合報告などから判断するしかありませんでしたが、 2005年頃に Ian Hickson が Google の収集したデータから得られた数値を HTML5 の開発に取り入れたことを契機に、できるだけ客観的な測定値をもとに議論する試みが広がってゆきました。
[7] HTML のような静的な対象については、調査の対象となるデータセットを整備し、 そこから機能の利用度を推測する方法が採られています。
[8] DOM API のようなスクリプトの機能については、 利用された回数を測定する use counter のような仕組みが Chrome や Firefox の開発版に組み込まれています。 2010年代に入ってからは、実装や仕様から機能を削除したり、大きく変更したりする時は、 計測結果を判断材料にしています。
[5] 確証はありませんが、Web互換という言葉が使われだしたのは00年代末か10年代初め頃ではないでしょうか。
[25] 00年代半ばまでは、 Web互換に相当する考え方は必ずしも広く受け入れられたものではありませんでした。 例えば00年代前半に W3C勧告となった DOM3 は、当時の Web の実態を無視して理論的な整合性や Java での実装可能性を重視して開発された節があります。 また00年代初頭に Webブラウザーに実装されたDOCTYPEスイッチは、 当時の Web の状態や実装の延長にある互換モードに加えて当時の仕様に基づく標準モードを追加するものでしたが、 現在でいう Web互換性を重視した前者のモードは移行措置であり、あまり重視されていませんでした。 (そのため軽度な非互換変更がいくつか加えられています。軽度で済まなかったものは、失敗に終わり元に戻されています。)
[16] Re: {Spam?} Re: [xhr] ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0416.html
[27] Editorial: web compatibility typically remains relevant · whatwg/dom@346e32c ( 版) https://github.com/whatwg/dom/commit/346e32c67ba976e6e4c10db8be1d216f34cd7e3b
marking WONTFIX unless someone can come up with a solution that does not break
the web.
[32] #SmooshGate FAQ | Web | Google Developers () https://developers.google.com/web/updates/2018/03/smooshgate
[33] Revive createObjectURL? · Issue #404 · w3c/mediacapture-main () https://github.com/w3c/mediacapture-main/issues/404
[34] Blink principles of web compatibility - Google ドキュメント () https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#