[9] Web 互換性compatibilityとは、現実の Web の世界との (主に Webサイトの HTML や JavaScript と、 あるいは Web鯖の挙動との) 互換性のことをいいます。 多くの場合、何らかの仕様書に明示されていない Webブラウザーの挙動について、 それに依存しているものが存在することをもって「Web互換性のために必要」 などと議論する時に使います。

[1] Web で利用されている技術は、広く利用されているため、その拡張や変更には色々な制限があります。 ある実装方法や拡張案を採用することによって現実に存在している文書やアプリケーションの動作に支障が出たり、 意図しない解釈をしてしまったりする場合があります。そういったものをWeb互換Web-compatibleでないといいます。

[2] 例えば、 Web 上の相当数の HTML文書は、 タグの入れ子関係が間違っているなど構文上の誤りを含んでいます。 構文的に正しくない HTML文書に遭遇した時に処理を停止し、エラーを表示するような実装は、 Web互換とは言えません。

[10] Webブラウザーおよび近代的なWeb標準の開発において、Web互換性は最も重要な性質の一つであると考えられています。 セキュリティ上必要な場合など極めて例外的な場合を除き、Web互換性の無い変更や新機能は Webブラウザーに実装されることはありませんし、Web互換性のために必要な機能が削除されることもありません。

[11] 歴史的には Web標準の制定プロセスにおいてWeb互換性は軽視されてきましたし、 現在でもなお IETF や W3C においては Web互換性の優先度は必ずしも高くありません。 むしろ理論的な合理性や既存の仕様書との整合性、政治的中立性が重視される傾向にあり、 市場と仕様が乖離する要因になっていました。

失敗した非互換変更

[3] Web互換でない変更が企てられたことは過去に何例かありますが、 多くは失敗しています。

強行された非互換変更

[4] セキュリティーを目的とした変更非互換変更は Web互換でなくても受け入れざるを得ないことがあります。 圧倒的なシェアを背景に強行される例もあります。

[26] Flash は、Web 上で広く使われており本来なら Web互換性のために実装しなければならないはずですが、 スマートフォンやタブレットの Webブラウザーからは排除されました。 一方でデスクトップブラウザーでは、他のプラグインが排除された後も、 Flash だけWeb互換性のために例外的に実装され続けています。

[35] 日本では MacJapanese も使われていましたが、今の Webブラウザーは表示できなくなっています。 今でも稀に遭遇することがありますが、文字化けしてしまいます。

Web 互換性の変化

[18] Web互換性は時代により変化します。ある機能が広く実装され利用されるようになると、 Web互換のために必要な機能に含まれるようになります。逆にある機能が利用されなくなり、 かつて利用されていた時代のWebサイトが機能しなくなったとしても構わないと思われる場合には、 Web互換のために必要な機能から外れます。

[19] ある時代にはWeb互換性のために必要だった(かもしれない)ものの、 その後必要でなくなり(ということにされ)削除された機能には次のものがあります。

[20] また次の機能はもはやWeb互換性のために不要として削除することが提案されています。

[21] ただ、一度複数の Webブラウザーで実装され広まった機能を削除するのは容易ではありません。 例えば現在ではフレーム (frameset) を使うことはほとんどありませんが、 かつてフレームを使って作られたページが大量に存在し、それらを閲覧できなくなるのは好ましくないため、 削除されていません。

[17] 次の非互換変更が提案されていますが、実施されるか、 されるとしていつになるかは不透明です。

Web の vendor 中立性と Web 互換性

[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非互換な変更とは考えられていません。

[15] IE10 は、 IE が10年間対応し続けてきた filter や VML を削除しました。 IE 専用のサイトなどでこれらの機能はよく用いられていましたが、 これらは元々 IE 以外では実装されておらず、 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構文解析器の動作の規定の根拠にはされませんでした。

Web 互換性の科学的測定

[6] 元々 Web互換性はWebブラウザー開発者と仕様開発者の経験や出荷後の不具合報告などから判断するしかありませんでしたが、 2005年頃に Ian Hickson が Google の収集したデータから得られた数値を HTML5 の開発に取り入れたことを契機に、できるだけ客観的な測定値をもとに議論する試みが広がってゆきました。

[7] HTML のような静的な対象については、調査の対象となるデータセットを整備し、 そこから機能の利用度を推測する方法が採られています。

[8] DOM API のようなスクリプトの機能については、 利用された回数を測定する use counter のような仕組みが Chrome や Firefox の開発版に組み込まれています。 2010年代に入ってからは、実装や仕様から機能を削除したり、大きく変更したりする時は、 計測結果を判断材料にしています。

「Web 互換性」の崩壊

[39] 平成時代末期頃から Chrome を中心に Web互換性を軽視して破壊的変更を加えることに躊躇がなくなる傾向が強まってきつつあります。

[40] 測定や統計による調査手法が確立されたために、数値が小さければ、あるいは「小さくなれば」、 機能を非互換変更したり削除したりしても構わないという風潮に変わってきています。

[41] しかし測定や統計はそもそも不完全なものであること、 性質上どうしても頻繁にアクセスされるページに偏ること、 特に古くなってたまにしか閲覧されないページの状況が正確に把握されないこと、 Webブラウザー事業者の従業員が英語 (せいぜい欧米圏) を中心に観測することによる偏向、 といった要素が見過ごされがちです。

[42] そもそもセキュリティーに関係する (と理由付けされる) 変更はあまり互換性が重視されない傾向がありました。 その他にも、 Webブラウザーのアーキテクチャーに大きく関わる変更 (主に機能の削除) は Webブラウザー事業者のモチベーションが大きいため積極的に進められがちです。 また、表示上の差異のみに関する変更は既存ページへの影響が軽視される傾向が強まっているように思われます。

[43] 令和に入ってからの事例でいえば、 h1 の利用者エージェントスタイルシート上の表示サイズの指定が突然削除されたりしています。 章節

[44] 表示に強いこだわりがあれば著者スタイルシートで明示しているだろうから大丈夫だろうという目論見での変更のわけですが、 その変更によって従来の大きさで問題なかったWebページの表示が崩れるという現象が実際に起こっています。 しかし見出しの表示の大きさが変わった程度だと、なんか表示がおかしいなあと困る程度の場合が多いので、大騒ぎにならず、 著者が変だなあと思って修正する羽目になるのです。Webブラウザー事業者はその修正コストに何の責任も負わないわけです。

[45] Webブラウザーの変更のせいだと気づいても、著者や利用者もまあこれくらい仕方ないと思ってしまうのですが、 それの積み重ねで大変なコストを負担させられていることに気づかないでいます。 あるいは、昨今の人気 Webサービスの API や JavaScript の人気ライブラリーは数ヶ月ごとに非互換変更されることもザラなので、 それに飼いならされた開発者たちは Web技術もそんなものだと思ってしまっているのかもしれません。

[36] Should we remove XSLT from the web platform? · Issue #11523 · whatwg/html, https://github.com/whatwg/html/issues/11523

[37] >>36 これを見るに「Web互換性」という概念はもうなくなってしまったし、 Webブラウザー事業者はもはや10年前のWeb頁が10年後も同じように表示されることを目標にしてくれないんだろうなあ。

[38] Google と Apple はともかく Mozilla も賛成となると Firefox の存在意義も既にないよなあ。

歴史

[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

[28] 149943 – Use "DNS pinning" to prevent Princeton-like exploits ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=149943#c66

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#