HTMLはなぜ「許す」言語なのか ―
エラーに寛容な設計思想の歴史と意味

あなたが書いたHTMLは、壊れていても動く

少し実験をしてみましょう。以下のHTMLをブラウザで開いてみてください。

<h1>こんにちは
<p>これは段落です
<p>これも<strong>段落</p>です

<h1> は閉じていません。2つ目の <p> の中で <strong> が開いたまま、</p> で段落が先に閉じています。文法的にはめちゃくちゃです。

しかし、ブラウザはこれを表示します。見出しは見出しとして、段落は段落として、太字は太字として——なんとなく「意図に近い」形で描画されます。エラーメッセージは出ません。白い画面にもなりません。

プログラミング言語の常識からすれば、これは異常なことです。PythonやJavaScriptで構文エラーがあれば、プログラムはその場で止まります。なぜHTMLだけがこんなに「甘い」のか。これは技術的な妥協や手抜きの結果ではありません。明確な設計思想に基づく、意図的な選択です。

ポステルの法則 ― 寛容さの原型

1980年、インターネットの前身であるARPANETで通信プロトコルの開発に携わっていたジョン・ポステルは、RFC 761の中でこう書きました。

「Robustness Principle（堅牢性の原則）」、通称ポステルの法則。ネットワーク上のノード（通信装置）が多少おかしなデータを受信しても、理解できる部分は処理し続けるべきだ——という考え方です。

なぜこれが重要だったのか。1980年代のネットワークは、今とは比べものにならないほど不安定でした。パケットは途中で壊れ、仕様の解釈は実装ごとにバラバラで、世界中のコンピュータが同じ言葉を正確に話すことなど到底期待できなかった。そんな環境で「完璧なデータ以外は拒否する」としたら、通信はほとんど成立しません。

ポステルの法則は、不完全な世界でシステムを動かし続けるための知恵でした。そして10年後、この思想はWebの言語にも受け継がれることになります。

「タグスープ」の時代 ― 寛容さが生んだ混沌

HTMLの寛容さは、最初から意図されていたわけではありません。というより、初期のHTMLには「正式な仕様書」すら存在しなかったのです。

1991年、ティム・バーナーズ＝リーがCERNで作った最初のHTMLは、SGMLという既存のマークアップ言語を簡略化したものでした。目的はシンプルで、研究者同士が文書を共有し、リンクで結びつけること。当時のWebブラウザ（バーナーズ＝リー自身が書いたWorldWideWeb）は、知らないタグに出会ったらそのタグを無視して中身だけを表示する——という実装になっていました。

この「知らないものは無視する」という振る舞いが、結果的にWebを爆発的に広げた要因の一つになりました。新しいブラウザが新しいタグをサポートしても、古いブラウザは壊れない。古いHTMLを新しいブラウザで開いても、壊れない。前方互換性と後方互換性が、設計ではなく副作用として手に入ったのです。

しかし1990年代後半、この寛容さは「Tag Soup（タグスープ）」という言葉で皮肉られるようになりました。Netscape NavigatorとInternet Explorerが市場シェアを奪い合う中、両社は独自のHTMLタグを次々と導入。<marquee>、<blink>、<font>——仕様にない要素が乱立し、ブラウザは「どんなに壊れたHTMLでも、なんとか表示する」ことを競い合いました。

結果として、Webの大部分は文法的に正しくないHTMLで構成されるようになりました。2008年のある調査では、Web上のページの95%以上に何らかのHTML文法エラーが含まれていたとも言われています。でも、それらはすべて表示されていた。ユーザーは何も気づかなかった。

これが「寛容さ」の光と影です。Webを誰にでも書けるものにした反面、HTMLの文法的な品質は限りなく低下しました。

XHTML 2.0 ― 「厳格さ」は拒絶された

タグスープの混沌に対し、W3C（World Wide Web Consortium）は「厳格さ」で応えようとしました。その結実が、2000年に策定されたXHTML 1.0です。

XHTML 1.0は、HTMLをXML（eXtensible Markup Language）の文法規則に従って書き直したもの。タグはすべて小文字、属性値は必ず引用符で囲む、空要素には閉じスラッシュを付ける。機能的にはHTML 4と同じですが、書き方が厳密になりました。

ここまでは現場にも受け入れられました。問題は、その次——XHTML 2.0です。

XHTML 2.0は、XMLの「ドラコニアンエラーハンドリング」（一つでもエラーがあれば即座に停止する処理モデル）を採用しようとしました。引用符が一つ欠けているだけで、ページ全体が表示されなくなる。理論的には美しい——完璧な文書しか存在しない世界。しかし現実のWebでは、95%以上のページが何らかのエラーを含んでいます。

現場のWeb制作者たちは、これを拒絶しました。そして代わりに、Mozilla、Apple、Operaのエンジニアたちが2004年にWHATWG（Web Hypertext Application Technology Working Group）を結成し、HTMLの「寛容路線」を引き継ぐ新しい仕様——のちのHTML5の策定を始めたのです。

2009年、W3CはXHTML 2.0の開発を正式に中止。HTMLの歴史における「厳格 vs 寛容」の戦いは、寛容の側の勝利で幕を閉じました。

HTML5のエラー回復 ― 「推測」が仕様になった

HTML5は、HTMLの寛容さを別の次元に引き上げました。それまでブラウザが独自に行っていたエラー回復のアルゴリズムを、仕様書として明文化したのです。

つまり、「壊れたHTMLをどう直して表示するか」のルールが、ブラウザごとの推測から、世界共通の標準になりました。<b><i>テキスト</b></i> というネストの間違いに対して、どのブラウザも同じ方法で回復する。これは、寛容さに秩序を与えた画期的な出来事でした。

これは「エラーを許すことが正しい」と宣言したわけではありません。HTML Validatorは今でも文法チェックに使えますし、正しいHTMLを書くことの重要性は変わりません。しかしHTML5は、「ユーザーの体験を壊さないことが最優先」という価値観を仕様レベルで確立した。壊れたHTMLを書いた制作者を罰する代わりに、ユーザーを守ることを選んだのです。

一方、JavaScriptは「許さない」

ここで対比として考えたいのが、JavaScriptの立ち位置です。

HTMLが宣言型言語（Declarative Language）であるのに対し、JavaScriptは命令型言語（Imperative Language）です。宣言型は「何を表示したいか」を記述し、命令型は「どう処理するか」をステップバイステップで指示する。この違いが、エラーへの態度を分けています。

HTMLでは、タグを閉じ忘れてもページは表示されます。CSSでは、知らないプロパティに出会ったら、その行だけをスキップして残りを適用します。しかしJavaScriptでは、セミコロンの欠落や未定義の変数参照など、一つの構文エラーがスクリプト全体の実行を停止させます。

<!-- HTML: エラーがあっても表示される -->
<p>段落1
<p>段落2  <!-- </p>がなくても両方表示される -->

// JavaScript: エラーがあると全体が止まる
console.log("これは表示される");
undefinedFunction();  // ← ここでスクリプト全体が停止
console.log("これは表示されない");

Jeremy Keithが著書『Resilient Web Design』で指摘しているように、現代のWeb開発はこの非対称性の上に危うく立っています。HTMLとCSSは壊れても「だいたい動く」。JavaScriptは壊れたら「全部止まる」。にもかかわらず、多くのWebサイトがJavaScriptに依存した構成になっている。

2015年、NASAがサイトをリニューアルしたとき、コンテンツの表示にJavaScriptが必須な構成にしました。JSの読み込みが完了するまで、訪問者が目にするのは真っ黒な画面だけ。テキストと画像——HTMLで十分に表現できるコンテンツを、わざわざJavaScriptで取得する設計にしたのです。ネットワークが不安定な環境、広告ブロッカーが干渉する環境、古いブラウザ——あらゆる「不完全」に対して、HTMLなら許されたはずのエラーが、JavaScriptでは致命的になる。

「許す」ことの現代的な意味

HTMLのエラー寛容性は、単なる技術的な仕組みを超えた、思想的なメッセージを含んでいます。

それは「参加の障壁を下げる」ということ。HTMLは、完璧なコードを書けるプロだけのものではありません。初めてメモ帳でタグを打った中学生のHTMLも、10年選手のフロントエンドエンジニアのHTMLも、ブラウザは同じように受け入れて表示します。この「敷居の低さ」が、Webを世界中に広げた最大の原動力でした。

今日、ReactやNext.jsのようなフレームワークが主流になる中で、HTMLを直接書く機会は減っているかもしれません。JSXの中にHTMLを書き、ビルドツールがそれを変換する。エラーはビルド時に検出され、ブラウザに届く前に弾かれる。ある意味で、XHTML 2.0が目指した「厳格な世界」は、フレームワークのレイヤーで実現されたとも言えます。

しかし、ブラウザが受け取る最終的なHTMLは、今でも「許す」言語です。この層がある限り、Webは「全か無か」のプラットフォームにはなりません。JavaScriptが読み込めなくても、CSSが壊れていても、HTMLだけは表示される。この最後の砦としての寛容さは、Webを他のあらゆるプラットフォームと区別する本質的な特徴です。

次にHTMLを書くとき——あるいはJSXの中にタグを並べるとき——少しだけ意識してみてください。そのタグは、壊れても表示される言語で書かれている。それは35年にわたる設計思想の結晶であり、Webが「世界でいちばん寛容なプラットフォーム」であり続けるための、静かな約束なのです。