第3章 なぜWebはHTMLを選んだのか
この章では、Web がなぜ HTML を中心に育ったのかを、PDF や Word との比較から捉えます。ゴールは、HTML の弱さや貧しさに見える点を「なぜその問題設定には合っていたのか」という観点で説明できるようになることです。
前章では、HTML が解決したかったのは CERN における情報共有の問題であり、URL や HTTP と分業してリンク可能な文書空間を作る役割だったと見ました。この章では、その問題設定に対して、なぜ HTML が他の文書形式より適していたのかを比べます。次章からは第2部に入り、そうして選ばれた HTML をブラウザがどこまで補完しながら扱うのかを見ていきます。
3.1 PDF は完成した版面には強いが、接続された文書空間には向いていなかった
まず、比較対象として分かりやすいのが PDF です。PDF は、完成した見た目を崩さずに配るのに非常に強い形式です。送った相手の環境が違っても、ほぼ同じ版面で読ませたい。印刷もしたい。ページ番号、余白、段組み、図版配置を固定したい。そういう目的には今でもよく合っています。
たとえば、研究所の装置マニュアルを「この順番、この図版配置、この脚注位置で配りたい」とします。その場合、多少環境が違っても同じ見た目を保てる PDF はかなり自然です。読む側がどの端末でも同じ版面を見られること自体が価値になるからです。
この強さは、同時に Web 初期の目的とは少しずれていました。CERN で必要だったのは、「このページをこの版面のまま読ませたい」ということより、「別の計算機からでも読めて、別文書へ飛べて、更新された情報にたどりつける」ことでした。完成した紙面に近い文書より、参照し続けられる文書のほうが重要だったのです。
ここで必要だったのは、印刷前の完成原稿ではなく、更新され続けるノートや手順書や記録でした。昨日の測定結果から関連装置の説明へ飛び、そこから担当者のメモへ移れることのほうが、紙面の固定より価値がありました。つまり問題は「きれいに配ること」ではなく、「つながった状態で読めること」でした。
極端に言えば、PDF は閉じた完成品として優秀です。一方、Web が必要としていたのは開いた途中経過でもつながる文書でした。ここを逆に理解すると、「PDF のほうが高機能なのに、なぜ HTML が広がったのか」という見え方になります。しかし実際には、先にあったのは機能競争ではなく、問題設定の違いでした。
誤解しやすいのは、ここで PDF を「技術的に劣る形式」として扱うことです。そうではありません。固定レイアウトという設計目標に対しては、むしろ HTML よりはるかに筋が通っています。Web が別の方向を向いていたため、中心にならなかっただけです。
3.2 Word は編集には強いが、共有の土台としては重すぎた
次に Word のようなワープロ文書を考えます。Word は編集しやすさに強みがあります。文字を打ち、見出しを付け、表や画像を入れ、履歴を見ながら文書を育てていく。人間が一つの文書を作業対象として扱うには、とても便利です。
しかし、共有の基盤として見ると事情が変わります。ワープロ文書は、編集環境、ソフトウェア、バージョン差、レイアウト依存の影響を強く受けます。しかも、文書の一部から別の文書の一部へ軽く飛ぶという発想は、中心ではありません。Word は「今この文書をどう作るか」に強いのであって、「文書どうしをどう結びつけるか」を第一の目的にはしていません。
たとえば、ある部署の手順書を 1 本の Word 文書で管理していたとして、その途中に「この装置の仕様は別文書のここを参照」と大量に埋め込みたい場面を考えます。作業者が異なる環境でそれを開き、最新版へ迷わず移動し、さらに別の関連文書へ辿れることまで含めて標準化するのは、ワープロ文書の得意分野ではありません。
この差は、前章で見た URL・HTTP・HTML の分業とも関係しています。Word 文書を取得することはできます。しかし、取得した文書を環境差を越えて安定して読み、さらに別文書への参照を土台から組み込み、たくさんの利用者が同じ構造を共有する、という条件では重くなります。Word は編集ツールとして強いが、Web が必要としていた公開された文書空間の共通形式としては向いていませんでした。
ここで大事なのは、Word が劣っていたと言いたいのではないことです。PDF と同じく、向いている問題が違っただけです。「何が高機能か」より「何を解決したいのか」で評価しないと、技術選択の筋道を見誤ります。
ここまでの違いを雑に 1 行で縮めると、PDF は完成した配布物、Word は編集する作業物、HTML はつながる公開文書に強い、となります。もちろん現実には機能の重なりもありますが、最初にどこへ最適化された形式なのかを押さえると、比較を誤りにくくなります。
3.3 HTML は「リンクできる文書」であることを最優先した
では HTML は何を優先したのでしょうか。答えはかなりはっきりしています。HTML の強みは、文書をリンク可能な構造として扱えることです。見出し、段落、リスト、リンクという最小の部品を使って、別の文書へ参照を張り、その参照を受け手の環境差を越えて共有できる。ここに Web の核がありました。
最小の例で見ると、HTML のリンクはこうです。
<h1>運転記録</h1>
<p>
今日のビーム状態は
<a href="beam-status.html">こちらの記録</a>
を参照してください。
</p>
この例の強みは、凝った見た目ではありません。重要なのは、文書の中に別文書への参照が自然に埋め込まれ、その意味が構造として共有されることです。PDF でもリンクは置けますし、Word でも参照は書けます。しかし HTML では、それが文書形式の中心にあります。リンクが脇役ではなく、文書を構成する基本動作になっているのです。
しかも、この参照はページ全体の見た目を固定しなくても成立します。見出しが多少違う幅で折り返されても、段落の行数が変わっても、リンクという機能自体は保たれます。ここでは版面の一致より、参照先へ確実に辿れることのほうが優先されています。
ここで前章の内容とつながります。HTML は URL や HTTP と分業することで、取得先、取得方法、文書構造をそれぞれ分けて持てました。そのため、文書を大きな一枚岩として閉じるのではなく、参照の網の中に置けます。Web に必要だったのは、まさにこの性質でした。
3.4 HTML は「見た目の厳密さ」より「環境差への強さ」を取った
HTML が PDF や Word より優れていたというとき、それは見た目の精密さの話ではありません。むしろそこでは HTML は不利です。フォント、余白、改ページ、紙面の完成度で見れば、PDF のほうがずっと強い場面があります。
それでも HTML が選ばれたのは、環境差に対して比較的強く、受け手に解釈を委ねながら読める形を保てたからです。送る側が完璧な完成版面を固定する代わりに、受け手のブラウザや環境でも読めることを優先する。その意味で HTML は、「完成品を配る形式」より「読めることを優先する形式」でした。
これは裏を返すと、送り手が細部の見た目を完全には支配できないということでもあります。HTML は、どの環境でもまったく同じ表示を保証するための形式ではありません。その代わり、受け手の装置やブラウザが違っても、文書構造とリンクを中心に内容へ辿りつきやすい。初期 Web では、この性質のほうが重要でした。
ここで誤解を潰しておきます。よく「HTML は貧弱だったから広まった」と言われます。しかし正確には、「当時の Web が解きたかった問題に対して必要十分だったから広まった」と言うべきです。貧弱さが偶然プラスに働いたのではありません。環境差を越えて読めること、リンクできること、更新された文書へ届きやすいことを優先した結果、HTML の単純さが強みになったのです。
この見方を持つと、HTML の後年の癖も少し見通しやすくなります。入力が多少壊れていても読めるようにする。古いページもなるべく壊さない。見た目の完璧さより閲覧可能性を優先する。これらはすべて、「まず届いて読めることを優先する」という初期の問題設定とつながっています。
この章ではまだ、ブラウザが具体的にどこまで補完するかまでは扱いません。その話を先取りすると第2部の重心が崩れるからです。ここでは、「なぜ HTML がそのような性格を持つ形式として選ばれたのか」までを押さえれば十分です。
3.5 実務では、形式の優劣ではなく問題設定との適合で考えたほうがよい
この章は歴史比較ですが、実務の判断にもかなり直結します。ある形式や技術を見るとき、「どれが高機能か」「どれが最新か」だけで比べると、用途とのずれを見落とします。
判断軸を表にすると、次のようになります。
| 形式 | 強い対象 | 優先するもの |
|---|---|---|
| 完成した配布物 | 版面の固定、印刷、同一見た目 | |
| Word | 編集中の文書 | 作成や修正のしやすさ |
| HTML | 公開される文書空間 | リンク、共有、環境差への強さ |
たとえば、印刷用の完成資料なら PDF が自然な場面があります。共同編集が主目的ならワープロ文書や別の編集環境が向くこともあります。一方で、ブラウザで配信し、リンクでつなぎ、検索や支援技術にも読ませたいなら、HTML の役割はまだ非常に強い。つまり、重要なのは形式の上下ではなく、どの問題設定にいちばん合っているかです。
Rails アプリでも、この見方はそのまま使えます。HTML を返す画面、PDF を出力する帳票、CSV を返すエクスポートでは、それぞれ解いている問題が違います。たとえば申請一覧の画面は HTML が向いています。検索結果にリンクを張り、詳細画面へ移動し、ブラウザで読み直せるからです。逆に、押印前提の帳票を毎回同じ見た目で出したいなら PDF が自然です。HTML が選ばれるのは、単に慣れているからではなく、リンクや構造共有やブラウザ表示という条件に合っているからです。この判断軸を持てると、「なぜ最終的に HTML へ落とすのか」を説明しやすくなります。
3.6 問題設定に合っていた形式
Web が HTML を選んだのは、PDF や Word より「上等」だったからではありません。HTML が最もよく合っていたのは、リンク可能な文書を、環境差を越えて共有し続けるという問題設定でした。PDF は完成版面に強く、Word は編集に強い。しかし Web が最優先したのは、閉じた完成品ではなく、参照の網の中に置かれた文書でした。
HTML は見た目の厳密さを多少手放す代わりに、リンク、配信、環境差への強さを取りました。その単純さは、貧弱さの裏返しではなく、当時の条件への適合でした。この視点があると、後の章で出てくるブラウザの補完や互換性重視の設計も、かなり自然に見えてきます。
次章からは第2部に入り、そうして選ばれた HTML をブラウザがどこまで完成させているのかを見ます。ソースコードを書いた人だけで文書が完結しているわけではない、という話がそこから始まります。