第22章 ブラウザ戦争が残したもの
「Best viewed in Netscape」——かつての Web には、こんなバッジが堂々と貼られていました。同じ Web のはずなのに、どのブラウザで見るかで表示が変わる。なぜ、そんな時代があったのでしょうか。
この章では、ブラウザ戦争を「昔は大変だった」で終えるのではなく、なぜ HTML とブラウザ実装が互換性にそこまで神経質になったのかを、その歴史的な理由から見ます。ゴールは、独自拡張が増えた時代を懐古的に眺めるのではなく、競争が Web に何をもたらし、何を壊しかけたのかを説明できるようになることです。
前章では、ティム・バーナーズ＝リーが Web を公開された土台として始めたことを見ました。この章では、その共有土台の上で Netscape と Internet Explorer が競争した結果、何が起きたかを扱います。Netscape も Internet Explorer も、当時の代表的な Web ブラウザです。次章では、その反省の先で、HTML が誰によってどう決められているかを見ます。
22.1 競争は Web を速く広げたが、同時に割った
1990 年代後半のブラウザ戦争では、Netscape と Internet Explorer が新機能を激しく競い合いました。短期的には、画像、スクリプト、レイアウト、埋め込み表現など、Web でできることが一気に増えました。その意味で、競争は Web を広げる推進力でもありました。
しかし同時に、その競争は「同じ Web を見る」という前提を壊しかけました。あるブラウザで動くページが別のブラウザでは崩れる。あるタグや API が片方にしかない。著者は、文書を書くというより、どのブラウザへ合わせるかを選ぶ作業へ引き寄せられていきます。
ここで問題だったのは、競争そのものではありません。共有された土台の上で、互換性より囲い込みが優先されやすくなったことです。Web は本来、別々の組織が公開した文書を相互に読めることに強みがありました。その基盤が、実装ごとの差で揺らぎ始めたわけです。
22.2 独自拡張は便利さと引き換えに分断を生んだ
この時代には、各社が独自タグや独自 API を打ち出しました。象徴的なのが、テキストを点滅させる Netscape の <blink> と、文字を横へ流す Microsoft Internet Explorer の <marquee> です。<blink> は開発者が酒場での雑談をきっかけに一晩で実装した、という逸話で知られ、どちらも標準には採用されず、<blink> はのちに各ブラウザから削除されました。著者から見れば、こうした独自機能は魅力的でもあります。新しい見た目や振る舞いをすぐ使えるからです。しかし、その便利さはしばしば「このブラウザで見てください」という条件とセットでした。当時のページに『Best viewed in Netscape』『Internet Explorer 推奨』といったバッジが当たり前のように貼られていたのは、文書が閲覧ソフトに縛られていたことの裏返しです。
たとえば、ブラウザごとに使える機能が違えば、著者は分岐を書いたり、場合によっては片方のブラウザを切り捨てたりします。文書を公開するはずの Web が、実際には閲覧ソフトごとの別世界へ分かれ始めるわけです。
あるページが Internet Explorer 向けの機能に依存して作られていれば、Netscape では意図どおりに読めません。逆も同じです。すると Web 文書は、公開された文書でありながら、実質的には特定の閲覧ソフトに縛られます。これは、第21章で見た出発点とかなり緊張します。
さらに厄介なのは、いったん広く使われた独自挙動は、あとで簡単に消せないことです。互換性のために残され、他社も追随せざるを得なくなる。第16章で見た「壊せない Web」は、こういう歴史ともつながっています。ブラウザ戦争が残したのは一時的な混乱だけではなく、長く尾を引く互換性負債でもありました。
22.3 標準化は理想論ではなく、疲弊への対策だった
この時代が残した最大の教訓は、互換性を市場競争だけに任せると、Web 全体が疲弊するということでした。著者は分岐だらけのコードを書くことになり、利用者はブラウザごとの差に振り回され、実装者は他社の独自挙動まで無視できなくなります。
だから標準化は、きれいごとのために強調されたのではありません。共有された仕様がなければ、同じ文書を相互に読めるという Web の基盤が持たないからです。今の HTML 仕様が、理想的な文法だけでなく、実際のパースやエラー回復、既存実装の挙動まで深く書くのは、この反省抜きには理解しにくい。
現在でもブラウザ間の競争は続いています。新機能の実装順、実験機能、開発者体験では差が出ます。ただし、少なくとも「各社が好き勝手に別々の HTML を作る」方向は、過去の失敗として共有されるようになりました。競争を否定したのではなく、競争を共有土台の上へ戻そうとしたのです。
22.4 ブラウザ戦争は現在の仕様の書き方を説明する
この章で伝えたいのは、ブラウザ戦争を昔話として覚えることではありません。HTML 仕様がなぜそこまで実装寄りで、互換性にうるさく、既存の挙動を無視できないのか。その理由の一部は、この時代の混乱にあります。
つまりブラウザ戦争が残したものは、独自機能の一覧ではなく、「共有された Web を保つには、共有されたルールが要る」という教訓です。第23章では、その教訓を受けて、いま HTML を誰がどのように決めているのかを見ます。