Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第1章 HTMLはプログラミング言語ではない

この章では、HTML を「処理を書く言語」ではなく「文書構造を記述する言語」として捉えます。ゴールは、HTML に iffor がないことを単なる不足ではなく、Web の基盤としての役割分担として説明できるようになることです。

前章にあたる前書きでは、「HTML は変な技術の寄せ集めではない」という本書全体の見方を示しました。この章は、その見方を最初に具体化する入口です。次章では HTML が何を解決したかったのかを CERN の情報共有という歴史から見ます。その前にまず、「HTML はそもそも何をする言語なのか」をはっきりさせておきます。

1.1 HTML は命令ではなく文書の役割を書く言語

プログラミング言語と聞くと、多くの人は条件分岐や繰り返しを思い浮かべます。if があり、for があり、値を保持する変数があり、処理の流れを自分で制御できる。JavaScript や Ruby はその意味で典型的なプログラミング言語です。

HTML は違います。HTML にあるのは、見出し、段落、リンク、画像、表、フォームのような文書の役割です。HTML が書いているのは「何を実行するか」ではなく、「この部分は何であるか」です。ここで言う「文書構造」とは、要素どうしの並びや階層だけではありません。見出し、段落、表といった意味上の役割まで含んだ構造です。

まず最小の例を見てください。

<h1>お知らせ</h1>
<p>会場が変更になりました。</p>

ここには命令がありません。あるのは「これは見出しです」「これは段落です」という構造だけです。しかもその構造は、単に箱が並んでいるという意味ではありません。「この部分は見出しとして読むべきだ」「この部分は段落として続けて読むべきだ」という意味の手がかりも含みます。HTML は画面の上で起きる処理を書くのではなく、そうした読み方まで含んだ文書の骨格を記述します。

この時点で、HTML は JavaScript や Ruby と別の種類の言語だと分かります。比較対象は「他のプログラミング言語」だけではありません。むしろ近いのは、文書に見出しや段落や脚注を付けるためのマークアップ言語です。マークアップ言語は、文章そのものに印を付けて「ここは見出し」「ここは段落」と役割を示す言語だと思えば十分です。HTML の M は Markup です。ここを見失うと、以後の章で出てくる多くの違和感が、「なぜこんな中途半端な言語なのか」という誤解に吸い込まれます。

1.2 だから HTML は CSS と JavaScript に役割を譲る

それでも実際の Web ページは、見出しや段落があるだけでは終わりません。色が付き、余白が付き、ボタンを押すと動きます。すると自然に、「結局いろいろやるなら、HTML が全部書けてもよかったのではないか」と思いたくなります。

しかし Web では、役割を分けたほうが都合がよい場面が多くありました。次の 3 つを見比べてください。

<h1 class="notice-title">お知らせ</h1>
<p id="notice-message">会場が変更になりました。</p>
.notice-title {
  color: #c00;
  margin-bottom: 0.5rem;
}
document.querySelector('#notice-message').hidden = false;

HTML が担当しているのは、「見出し」と「段落」という構造です。CSS は色や余白のような見た目を担当します。JavaScript は表示・非表示の切り替えのような振る舞いを担当します。

この分業は、ただ習慣でそうなったわけではありません。文書の構造、見た目、振る舞いは、変わる速さも、読む主体も、壊れたときの影響範囲も違います。見出しは検索エンジンや支援技術も読みますが、赤色かどうかはそうではありません。クリック時の動きは JavaScript が担いますが、見出しであること自体は JavaScript がなくても成立します。

つまり HTML が全部を抱えないのは、弱いからではありません。むしろ、何を自分の責務として持ち、何を他に任せるかをかなり明確に切り分けているからです。

1.3 iffor がないことは欠陥ではなく前提

ここで、よくある違和感を、逃げずに扱っておきます。HTML を初めて本格的に触ると、「どうして条件分岐も繰り返しも書けないのか」と感じます。テンプレートエンジンや JSX に慣れていると、この違和感はなおさら強くなります。

たとえば Rails の ERB では、次のように書けます。

<% if @articles.any? %>
  <ul>
    <% @articles.each do |article| %>
      <li><%= article.title %></li>
    <% end %>
  </ul>
<% end %>

この例で ifeach を担当しているのは Ruby です。HTML は、その結果として出力される ulli の構造だけを担当します。React の JSX でも事情は同じです。条件分岐や反復は JavaScript が書き、最終的にブラウザへ渡るときには HTML に相当する構造へ変換されます。

この事実は重要です。現代の開発者はしばしば、テンプレート言語やフレームワークの中で HTML を見ています。そのため、「HTML が条件分岐できている」ように見えることがあります。しかし本当は、条件分岐しているのは周辺の言語です。HTML 自体は最後まで、構造を表す役割に留まっています。

だから、HTML に iffor がないのは単なる未熟さではありません。HTML は最初から、処理系ではなく文書構造の共通表現として設計されていたからです。もし HTML 自体が複雑な処理を抱えていたら、ブラウザ以外の多くの読み手にとって扱いにくい形式になっていたはずです。

1.4 HTML が Web の基盤になれたのは読む主体が多かったから

「プログラミング言語ではないのに重要」という言い方には、まだ少し飛躍があります。そこで最後に、なぜ HTML が Web の基盤になれたのかを、読む主体の広さから押さえます。

ブラウザは HTML を読んで画面を作ります。これは直感的です。しかし HTML を読むのはブラウザだけではありません。検索エンジンは見出しやリンクの構造から文書の手がかりを拾います。スクリーンリーダーのような支援技術は、見出しやリストや表の構造を頼りに読み上げの順序を組み立てます。ここでいう支援技術は、画面を読み上げたり操作を助けたりして、情報へアクセスしやすくする道具です。アーカイブツールや変換ツールも、HTML を文書の骨格として読みます。

ここで大事なのは、これらの読み手が求めているのは「どう動くか」より先に「何であるか」だという点です。ある文字列が赤いかどうかより、それが見出しなのか、段落なのか、リンクなのかのほうが重要な場面が多くあります。HTML はまさにその情報を渡すための形式でした。

補足: もちろん現代の Web ページは JavaScript に強く依存することもあります。ただし、それでも最終的には多くの場合、ブラウザや他の利用者が読める HTML の構造へ落ちます。周辺技術が進化しても、HTML の役割が消えないのはこのためです。

誤解されやすいのは、「HTML は簡単だから基盤になった」という言い方です。正確には少し違います。HTML は文書構造に責務を絞っていたから、多くの主体が共有しやすい形式になりました。条件分岐や計算のような処理を抱え込まなかったからこそ、ブラウザ以外にも読まれやすい、長寿の土台になれたのです。

1.5 実務では「HTML だけで何でもやる」発想を疑う

この章の話は歴史や思想の説明に見えますが、実務上の判断にもつながります。HTML を構造記述の言語として見る癖が付くと、マークアップが崩れているときの違和感が変わります。

たとえば、見た目だけを合わせるために何でも div で囲っていないか、見出しにすべき箇所がただの太字テキストになっていないか、表として読むべき情報を無理に別の要素で並べていないか、という見方ができるようになります。言い換えると、「この書き方は見た目しか満たしていないのではないか」と疑う視点が持てます。逆に、HTML に本来ない責務を押しつけ始めると、後から CSS、JavaScript、検索、支援技術のどこかで痛みます。

この章の段階で「こう書けば正解」という細則を覚える必要はありません。ここで押さえておきたい判断基準は一つです。HTML は処理や見た目を全部抱える言語ではなく、文書構造を共有するための言語だということです。この前提を持つだけで、後の章で出てくる tabledivh1 の議論の見え方がかなり変わります。

1.6 構造記述という前提

HTML はプログラミング言語ではありません。iffor がないのは、能力不足だからではなく、文書構造を記述する役割に責務を絞っているからです。見出し、段落、リンク、表、フォームといった要素は、「どう処理するか」ではなく「それが何であるか」を表します。

この役割分担があるからこそ、見た目は CSS に、振る舞いは JavaScript に譲れます。そしてその結果、HTML はブラウザだけでなく、検索エンジン、支援技術、各種ツールが共有できる土台になりました。HTML に処理を書けないことは、Web の基盤として見ると欠陥ではなく前提です。

次章では、その前提の上で、HTML がそもそも何を解決したかったのかを見ます。文書構造を記述するという役割は、どこから必要になったのか。1980 年代末から 1990 年代初頭の CERN では、まさにその共有の問題が切実でした。そこから HTML の歴史に入ります。

参考資料