[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)[ - [[AppCache]] の [CODE[SecureContext]] 限定 - [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]] の採用 - [[secure origin]] 以外での [[Geolocation API]] の無効化 - [CODE[image-orientation]] ]FIG] [26] [[Flash]] は、[[Web]] 上で広く使われており本来なら [[Web互換性]]のために実装しなければならないはずですが、 [[スマートフォン]]や[[タブレット]]の [[Webブラウザー]]からは排除されました。 一方で[[デスクトップブラウザー]]では、他の[[プラグイン]]が排除された後も、 [[Flash]] だけ[[Web互換性]]のために例外的に実装され続けています。 [35] [[日本]]では [[MacJapanese]] も使われていましたが、今の [[Webブラウザー]]は表示できなくなっています。 今でも稀に遭遇することがありますが、[[文字化け]]してしまいます。 * Web 互換性の変化 [18] [[Web互換性]]は時代により変化します。ある機能が広く実装され利用されるようになると、 [[Web互換]]のために必要な機能に含まれるようになります。逆にある機能が利用されなくなり、 かつて利用されていた時代の[[Webサイト]]が機能しなくなったとしても構わないと思われる場合には、 [[Web互換]]のために必要な機能から外れます。 [19] ある時代には[[Web互換性]]のために必要だった(かもしれない)ものの、 その後必要でなくなり(ということにされ)削除された機能には次のものがあります。 [FIG(list short)[ - [CODE(HTMLe)@en[[[basefont]]]] - [[フレーム]]無効の表示モード - [[VRML]] - [[Gopher]] - [[XBM]] - [[ステータスバー]] - [[Java]] -- [CODE[applet]] -- [[LiveConnect]] - [[NPAPI]] - [[Flash]] - [CODE(DOMm)@en[[[showModalDialog]]]] - [CODE(HTMLe)@en[isindex]] - [CODE(DOMi)@en[DOMError]] - 非 [[FTP]] の[[部分資源]]としての [[FTP]] ]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)[ - [[同期]] [[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]]) ]REFS] * 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ブラウザー事業者]]のモチベーションが大きいため積極的に進められがちです。 また、表示上の差異のみに関する変更は既存ページへの影響が軽視される傾向が強まっているように思われます。 [EG[ [43] [[令和]]に入ってからの事例でいえば、 [CODE[h1]] の[[利用者エージェントスタイルシート]]上の表示サイズの指定が突然削除されたりしています。 [SEE[ [[章節]] ]] [44] 表示に強いこだわりがあれば[[著者スタイルシート]]で明示しているだろうから大丈夫だろうという目論見での変更のわけですが、 その変更によって従来の大きさで問題なかったWebページの表示が崩れるという現象が実際に起こっています。 しかし[[見出し]]の表示の大きさが変わった程度だと、なんか表示がおかしいなあと困る程度の場合が多いので、大騒ぎにならず、 [[著者]]が変だなあと思って修正する羽目になるのです。[[Webブラウザー事業者]]はその修正コストに何の責任も負わないわけです。 [45] [[Webブラウザー]]の変更のせいだと気づいても、[[著者]]や[[利用者]]もまあこれくらい仕方ないと思ってしまうのですが、 それの積み重ねで大変なコストを負担させられていることに気づかないでいます。 あるいは、昨今の人気 [[Webサービス]]の [[API]] や [[JavaScript]] の人気[[ライブラリー]]は数ヶ月ごとに[[非互換変更]]されることもザラなので、 それに飼いならされた開発者たちは [[Web技術]]もそんなものだと思ってしまっているのかもしれません。 ]EG] [36] [CITE@en[Should we remove XSLT from the web platform? · Issue #11523 · whatwg/html]], [TIME[2025-08-06T01:26:36.000Z]] [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] [CITE@en[Re: {Spam?} Re: ''''''[''''''xhr'''''']'''''']] ( ([[Anne van Kesteren]] 著, [TIME[2014-09-04 02:49:30 +09:00]] 版)) [27] [CITE@en[Editorial: web compatibility typically remains relevant · whatwg/dom@346e32c]] ([TIME[2016-04-16 13:06:56 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [28] [CITE@en[149943 – Use "DNS pinning" to prevent Princeton-like exploits]] ( ([TIME[2016-06-16 18:41:03 +09:00]])) ]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]]) [33] [CITE@en[Revive createObjectURL? · Issue #404 · w3c/mediacapture-main]] ([TIME[2018-04-19 13:17:16 +09:00]]) [34] [CITE@ja[Blink principles of web compatibility - Google ドキュメント]] ([TIME[2019-08-14 15:53:23 +09:00]])