第15章 互換性はなぜ重要なのか
この章では、後方互換性を「古いものを切れない保守性」とだけ見るのではなく、公開済みの文書を読めるまま保つための Web の責務として見ます。後方互換性は、新しい実装になっても古いページや古い書き方をなるべく読めるままにする性質だと思えば十分です。ゴールは、互換性を単なる技術的惰性ではなく、「昔のページが今日も読める」ことを支える設計判断だと説明できるようになることです。
前章では、XHTML の厳密さが公開 Web には重すぎたことを見ました。この章では、その帰結として、なぜ Web が「壊さないこと」を強く優先するのかを扱います。次章では、その責務がバグの温存にまで及ぶ例を見ます。
15.1 公開されたページは作者の手を離れて生き続ける
多くのソフトウェアでは、新しい版に合わせて古い利用者が移行することがある程度前提になります。アプリケーションなら、提供者が更新のタイミングをある程度コントロールできます。
しかし Web ページは違います。いったん公開された文書は、作者が更新を止めても、リンクされ、検索され、保存され、あとからも読まれ続けます。しかも、そのページの作者にもう連絡できないことも珍しくありません。
この条件では、ブラウザの新しい版が「古い書き方は切り捨てる」と決めた瞬間に、誰にも直せないページが壊れます。だから Web における互換性は、古い実装への情けではなく、公開された文書空間を維持するための責務になります。
しかも失われるのは、個人の趣味ページだけではありません。昔の技術記事、研究資料、企業の告知、行政情報のように、あとから参照され続ける文書も含まれます。互換性の問題は、開発者の都合だけではなく、社会に残った記録をどこまで読み続けられるかという問題でもあります。
15.2 Quirks Mode は不格好でも必要だった
この責務がよく見えるのが Quirks Mode です。これは、古いページを当時に近い癖で読むための互換モードだと思えば十分です。理想だけを言えば、すべてのページを同じ標準モードで処理したほうが単純です。けれど現実には、過去のブラウザ依存の挙動を前提に作られたページが大量にありました。
そこでブラウザは、条件によって標準モードと互換モードを切り替え、古いページでは過去の挙動へ寄せる道を残しました。標準モードは現在の標準に沿って読むモード、互換モードは古い挙動へ寄せて読むモードです。Quirks Mode は、美しい設計の勝利ではありません。むしろ、理想だけでは既存ページを守れなかったからこそ生まれた緩衝材です。
ここで重要なのは、Quirks Mode を単なる恥ずかしい互換レイヤーとして笑わないことです。あれは「標準に従わなかったページを甘やかした」だけではなく、「すでに公開され、現に読まれている文書を急に壊さない」ための現実的な責任の取り方でもありました。
15.3 互換性は実装の負債ではあるが、Web の価値も支えている
もちろん互換性にはコストがあります。実装は複雑になり、仕様書も長くなり、設計をきれいに保ちにくくなります。第12章で見た仕様書の巨大さの一部も、この負債と無関係ではありません。
それでも Web が長く使える基盤でいられたのは、その負債を引き受けてきたからです。昔のリンクが急に全部無効にならない。古い記事が、数年後もだいたい読める。企業サイトも個人ブログも研究ページも、完全ではなくても残り続ける。この性質は、単なる技術選好ではなく、Web の価値そのものです。
XHTML が広がりにくかったのも、ここにつながります。入力の厳密さを優先して古いページが壊れやすくなるなら、公開文書空間としての Web の価値が下がってしまう。だから Web は、きれいさだけではなく、壊さない責任を優先する方向へ寄りました。
15.4 「古いものを残す」と「何も変えられない」は別である
ここで誤解しやすいのは、互換性を重視するなら何も改善できないのではないか、という見方です。実際にはそうではありません。Web は、新しい要素や API を足しながら、古いページもなるべく壊さないよう進んできました。
大事なのは、変更のしかたです。既存ページの意味を壊す形で一気に切り替えるのではなく、新しい仕組みを足し、古い仕組みは読めるまま残す。この慎重さが、Web を遅く見せることもあります。しかしその遅さは、公開済みの文書と利用者を置き去りにしないための遅さでもあります。
ここまでで、互換性は古いものへの未練ではなく、公開された文書を基盤として引き受ける責務だと分かりました。次章では、その責務がさらに進んで、仕様上あまり好ましくないバグさえ簡単には消せなくなる理由を見ます。