865.txt

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

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

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

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

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

* 失敗した非互換変更

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

[FIG(list middle)[
- [CODE(DOMi)@en[DOMStringList]] の廃止
- [CODE(DOMe)@en[click]] [[イベント]]の[[副作用]]の廃止
- [CODE(DOMi)@en[CDATASection]] の廃止
- [[XML文書]]の [CODE(DOMm)@en[createElement]] の[[名前空間URL]]の扱い
- [[属性選択子]]の[[ASCII大文字・小文字不区別]]性の変更
- [[AttrExodus]]
- [[IE10]] における [[Flash]] の排除
- [[Chrome]] における [[H.264]] の削除
- [[RDFa]]
- [[無奇癖モード]]における[[注釈]]の[[構文解析]]の変更
- [[RSS]]/[[Atom]] の [CODE(XMLa)@en[[[xml-stylesheet]]]] の無視
- [[HTML]] への [[XML名前空間]]構文の追加
- [[XHTML]] への移行
- [[Strict DTD]] への移行
- [[Netscape Cookie]] から [[IETF Cookie]] への置き換え
- [[GIF]] から [[PNG]] や [[MNG]] への移行
- [[HTML]] の [[SGML]] 化
- [[[CODE[open]] (XHR)]] の [[URL]] の [[UTF-8]] 固定
]FIG]

* 強行された非互換変更

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

[FIG(list middle)[
- [CODE(HTMLe)@en[keygen]] の廃止
- [CODE(DOMe)@en[beforeunload]] の文面無視
- [[NPAPI]] の廃止
- [[SSL 3.0]] の削除
- [[Mixed Content]] 規制の強化
- 旧版 [[WebSocket]] の削除
- [[IE]] の[[XSS防護]]機能
- [[スマートフォン]]における [[Flash]] の事実上の排除
- [[スマートフォン]]における[[ガラケー版]]独自仕様への非対応
- [[ポップアップ]]の抑制
- [[SSL 2.0]] の削除
- [[平文]] [[WebDAV]] の[[basic認証]]の排除
- [[ガラケー版]]独自仕様の [[HTML]] や [[CSS]] の採用
- 非 [[FTP]] の[[部分資源]]としての [[FTP]]
]FIG]

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

* Web 互換性の変化

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

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

[FIG(list short)[
- [CODE(HTMLe)@en[[[basefont]]]]
- [[フレーム]]無効の表示モード
- [[VRML]]
- [[Gopher]]
- [[XBM]]
- [[ステータスバー]]
- [[LiveConnect]]
- [[Java]]
- [[Flash]] 以外の [[NPAPI]]
- [CODE(DOMm)@en[[[showModalDialog]]]]
- [CODE(HTMLe)@en[isindex]]
- [CODE(DOMi)@en[DOMError]]
]FIG]

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

[FIG(list)[
- [[navigate]] における [CODE(MIME)@en[[[multipart/x-mixed-replace]]]]
- [[HTTP]] からの [CODE(URI)@en[ftp:]] [[fetch]]
]FIG]

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

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

[FIG(list)[
- [[secure origin]] 以外での [[Geolocation API]] の無効化
- [[同期]] [[XHR]] の廃止
- [[SVG]] の[[構文解析器]]を [[XML]] から [[HTML]] に変更
- [[XSLT]] の削除
- [[AppCache]] の廃止
- [[mutation event]] の廃止
- [[FTP]] [[fetch]] の廃止
]FIG]

* Web の vendor 中立性と Web 互換性

[12] [[Web互換性]]は、 [[Web]] が [[vendor]] 中立であり、
複数の[[相互運用性]]の高い実装が共存していることを前提に成立しています。
[[Webブラウザー]]は複数存在し、それぞれが (大部分で重なりつつも) 異なる [[Web]] 
技術を実装ています。[[著者]]はその差異を認識し、いずれの [[Webブラウザー]]でも意図通りに動作させられる範囲内で
[[Web]] 技術を用いることを (幸か不幸か) 要求されています。

[13] いずれかの [[Webブラウザー]]でしか実装されていない機能や、
[[Webブラウザー]]同士で異なる方法で実装されている機能を用いたとすると、
すべての [[Webブラウザー]]で正しく動作する[[文書]] ([[Webアプリケーション]]) とはなりません。
その場合、仮に特定の [[Webブラウザー]]でのみ正しく動作していたとしても、
[[Web]] 全体として見た時その[[文書]]ははじめから「壊れて」います。
その [[Webブラウザー]]が以後の版でその機能の実装方法を変更したり、
機能自体を削除したりして、その[[文書]]がその [[Webブラウザー]]でさえ正しく動作しなくなったとしても、
元から「壊れて」いたものがより壊れただけです。
[[相互運用性]]の低い機能の変更や削除は、 [[Web非互換]]とは考えられていません。

[EG[
[14] 例えば [[Google]] は [[Chrome]] で [[Web Intents]] を実装しました。
いくつかの [[Webアプリケーション]]はこれを利用しました。その後 [[Chrome]]
は [[Web Intents]] を削除し、そのような [[Webアプリケーション]]は動作しなくなりました。
しかしこれは [[Web非互換]]な変更とは考えられていません。
]EG]

[EG[
[15] [[IE10]] は、 [[IE]] が10年間対応し続けてきた [CODE(CSS)@en[[[filter]]]]
や [[VML]] を削除しました。
[[IE]] 専用のサイトなどでこれらの機能はよく用いられていましたが、
これらは元々 [[IE]] 以外では実装されておらず、
[[Web非互換]]な変更ではありません。
]EG]

* 閉鎖的環境における Web 非互換な機能

[22] [[Web]] の技術を用いているものの、特定の分野の要求に基づき独自のアレンジを加えて利用している環境
(いわゆる [[walled garden]]) では、[[Web非互換]]な独自の機能が実装されている (されていた)
ことがあります。

[23] 次のような例があります。

[FIG(list)[
- [[ガラケー]]環境における独自の[[シフトJIS]]や[[HTML]]、[[CSS]]
- [[WAP]] 環境における [[WML]] で拡張された [[XHTML]]
- [[Dashboardウィジェット]]における [CODE(HTML)@en[<[[script]]/>]] の[[構文解析]] (>>31)
- [[Firefox拡張]]や[[Chrome拡張]]などにおける[[特権]]的なアクセス
- [[アプリ内ブラウザー]]の特殊機能
- [[Webアプリケーション]]の[[関門]]の裏側でのみ用いる[[アプリケーションサーバー]]の簡略化された
[[HTTP]] の実装
]FIG]

[24] こうした非互換な機能は、最初は良くても、あるいは当該環境の提供者には都合が良くとも、
次第に [[Web]] との一体性が高まって不都合が生じたり、
[[Web]] と独自環境で2種類の実装を維持することが (環境の提供者にとってもその環境へのコンテンツの提供者にとっても) 負担になったりして不具合の温床になったり、
やがてメンテナンスされなくなって放棄されたりする一因になることがよくあります。

-*-*-

[29] [[Web互換性]]の議論では、[[ブラウザー拡張]]や[[アプリ内ブラウザー]]を含め、
[[Webプラットフォーム]]に属さない分野の個別の事情は原則として考慮されません (具体例 >>20)。
そうした独自の[[プラットフォーム]]での[[互換性]]の維持は、
[[Web標準]]開発全体の責務ではなく、当該[[プラットフォーム]]の提供者の責務と考えられます。

[30] 現実には、 [[Web]] の技術の特定の実装の挙動がその実装を使った[[プラットフォーム]]ではよく使われて、
[[Web]] 全体では使われていない、ということがしばしば起こります。
当該[[プラットフォーム]]の提供者は、 (元々単一であった技術を) [[Web]] とそれ以外とで別の動作モードに分けて互換性を維持するか、
独自[[プラットフォーム]]の挙動を非互換に変更するかといった選択を迫られることになります。

[EG[
[31] [[Dashboardウィジェット]]では [CODE(HTML)@en[<[[script]] '''/'''>]]
が[[空要素]]として解釈されることになっていました。
標準の [[HTML構文解析器]]ではそのような挙動は認められていませんが、
既存の[[Dashboardウィジェット]]との互換性を保つため、
標準とは異なる構文解析モードが必要となりました。

これは有名な事例で、 [CITE[HTML Standard]] の編集者らも当然承知していましたが、
そのような挙動を標準の [[HTML]] に取り込むと [[Web]] 側で互換性の問題が生じるため、
どれだけ影響を受ける[[Dashboardウィジェット]]が多いとはいっても、
[[HTML構文解析器]]の動作の規定の根拠にはされませんでした。
]EG]

[REFS[
- [20] [CITE@en[initEvent should not require three parameters · Issue #387 · whatwg/dom]]
([TIME[2017-01-14 16:56:56 +09:00]])
<https://github.com/whatwg/dom/issues/387>
]REFS]

* Web 互換性の科学的測定

[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] [CITE@en[Re: {Spam?} Re: ''''''[''''''xhr'''''']'''''']]
( ([[Anne van Kesteren]] 著, [TIME[2014-09-04 02:49:30 +09:00]] 版))
<http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0416.html>

[27] [CITE@en[Editorial: web compatibility typically remains relevant · whatwg/dom@346e32c]]
([TIME[2016-04-16 13:06:56 +09:00]] 版)
<https://github.com/whatwg/dom/commit/346e32c67ba976e6e4c10db8be1d216f34cd7e3b>

[FIG(quote)[
[FIGCAPTION[
[28] [CITE@en[149943 – Use "DNS pinning" to prevent Princeton-like exploits]]
( ([TIME[2016-06-16 18:41:03 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=149943#c66>
]FIGCAPTION]

> marking WONTFIX unless someone can come up with a solution that does not break
> the web.

]FIG]


[32] [CITE@en[#SmooshGate FAQ  |  Web  |  Google Developers]]
([TIME[2018-03-20 07:16:16 +09:00]])
<https://developers.google.com/web/updates/2018/03/smooshgate>