第16章 バグはなぜ残るのか
この章では、Web に残るバグを単なる怠慢や技術不足としてではなく、互換性が正しさの条件に入り込んだ結果として見ます。ゴールは、「直したほうが正しいはずの挙動」がなぜ簡単には直せないのかを、実装の甘さではなく、公開済みの Web を壊さない責務から説明できるようになることです。
前章では、互換性が公開文書空間を維持する責務だと見ました。この章では、その責務がどこまで重くなるかを、バグの残存という形で見ます。次の第5部では、この複雑さを前提に、HTML を巡る有名な議論を整理していきます。
16.1 「直せばよい」が通らない世界
普通の感覚では、バグは見つけたら直すべきものです。その判断自体は間違っていません。実際、ブラウザ実装者も好んで不具合を残したいわけではありません。
しかし Web では、ある挙動が長く存在すると、既存サイトの HTML、CSS、JavaScript がその挙動を前提に組まれてしまうことがあります。すると、実装上は望ましくないふるまいでも、急に正してしまうと現実のページが壊れます。
ここで難しいのは、「仕様どおりに直す」ことと「現に動いている Web を壊さない」ことが一致しない場面があることです。第15章で見た互換性の責務は、ここで単なる保守性ではなく、実装判断そのものを縛る条件になります。
16.2 互換性が正しさの一部になってしまう
この問題が厄介なのは、バグと正しさの境界が固定されていないことです。実装者が「これはおかしい」と思っていても、その挙動に依存するページが大量にあるなら、修正による破壊コストが無視できません。
その結果、Web では「現実に壊さないこと」が、正しさの条件の一部へ入り込んできます。仕様が既存実装を吸い上げる形で整理されることがあるのも、そのためです。理屈だけなら不要な挙動でも、広く使われているなら、単純に消すより先に「どう整合させるか」を考えなければなりません。
第12章で見たように、仕様書は理想の定義集であると同時に、実装をそろえるための文書でもあります。そこに第15章の互換性責務が重なると、「既存実装ではこう動き、しかも多くのページがそれを前提にしている」という事実そのものが、仕様整理の条件へ入ってきます。ここでは、仕様、実装、既存ページが互いに切り離せなくなっています。
これは、バグを正当化する話ではありません。むしろ逆で、Web では何を正しいと呼ぶか自体が、実装、仕様、既存ページの三者関係の中で重くなる、という話です。
16.3 バグが残るのは、ブラウザが公共基盤だからである
ここで第3章まで戻ると、Web は最初から閉じたアプリケーション配布基盤ではなく、公開された文書空間でした。誰かのサーバーにあるページを、別の誰かのブラウザが読み続ける。この前提がある限り、ブラウザは単なる1社の製品では済みません。
公共基盤に近いものほど、「理屈では正しい更新」がそのまま許されにくい。道路標識のルールを一夜で変えにくいのと少し似ています。もちろん完全に同じではありませんが、変化のコストを利用者全体が負う点では近いものがあります。ブラウザのバグが簡単に消せないのも、個別製品の品質問題というより、基盤としての責任が重いからです。
この重さを理解すると、HTML やブラウザの変化が遅く見える理由も変わってきます。遅いのは、怠けているからではなく、壊したときの影響範囲があまりにも広いからです。
16.4 「バグが残る」ことと「改善を諦める」ことは別である
ここで誤解したくないのは、では Web は何も改善できないのか、という点です。実際には、実装者も標準化側も、壊れにくい形で修正や整理を進めています。問題は、正しさだけを基準に一気に切り替えにくいことです。
だから Web の改善は、追加、段階的移行、警告、互換レイヤーの維持といった慎重な手順を取りがちです。見た目には回りくどくても、それは既存の文書と利用者をまとめて崩さないための回り道でもあります。
ここでのポイントは、「直せない」のではなく「どう直すかが厳しく制約される」ことです。修正そのものを諦めるのではなく、破壊コストを下げながら移す道を探す。その慎重さまで含めて、Web の改善は設計されています。
ここまでで、バグが残るのは不完全さの証拠であると同時に、壊せない基盤であることの裏返しでもあると分かりました。第4部を通して見えてきたのは、HTML の歴史が理想と現実のどちらか一方ではなく、そのあいだで責任を引き受け続けてきた歴史だということです。次の第5部では、その前提の上で、h1、table、div、b を巡る有名な議論を整理していきます。