0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

HTML再入門 -仕様の混乱と現状-

Last updated at Posted at 2025-11-11

概略

今日では WWWはインターネットの代表的なサービスとして、様々な用途で使われています。そのWWWの最初の構成要素はハイパーテキスト HTML とそれを送受信する通信プロトコル HTTPでした。現在において WWWを活用したサービスやセキュリティを学ぶために、その基本となるHTMLを振り返りたいと思います。

本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。

HTMLの誕生

1990年代初頭、ティム・バーナーズ=リー(Tim Berners-Lee)氏がCERNで考案したHTMLは、文書内の「構造」を表現することに主眼を置いた言語でした。見出し、段落、リンクといったシンプルな要素のみを備え、ウェブは「文書をハイパーリンクでつなぐ仕組み」として動き出しました1

やがてCERNから外部にも公開されると、1993年にMosaicなどのブラウザーが登場し、研究者だけでなく一般の利用者にも広まり始めました。この時期、HTMLの仕様は草稿レベルの文書が流通していただけで、実装は各ブラウザー開発者の解釈に委ねられていました。そのため早くも機能追加や独自拡張が乱立し、統一的な標準が求められるようになりました。

HTMLの標準化と混乱

HTMLの標準仕様

こうした状況を受け、インターネット技術標準を策定していたIETF(Internet Engineering Task Force)によって、仕様の標準化が進められました。その成果として、一般的に使用されていたHTMLの機能を整理して、1995年にIETFにより HTML2.0 (RFC1866) として勧告されました。HTML2.0は、後のブラウザー拡張で登場する<font>や<center>といった見た目の要素を含まず、あくまでリンク・段落・リスト・フォームといった基本的な構造要素を規定するものでした。

その後、HTML2.0を拡張しようとした試みとして HTML+ が1993年に提案されました2。HTML+は数式表現や表組み、脚注、図版のキャプションなど、より豊富な表現を可能にすることを目的としたものでした。しかし、仕様が急速に膨らみすぎ、当時のブラウザー実装が追随できず、RFCとしての勧告には至りませんでした。

HTMLの標準化をより広範に推進する新しい組織が求められるようになり、1994年10月にW3C(World Wide Web Consortium)が設立されました。W3CはCERNとMITを中心に、産業界と学術界を横断する国際的な標準化団体としてスタートし、HTMLの仕様策定もIETFからW3Cへと引き継がれる形となりました。IETFのHTMLワーキンググループは1996年をもって活動を終了しています。

W3Cは「HTML3.0」という仕様案を策定しようとしました。ここでは数式表現(MathMLの先駆け)やテーブル機能の強化など、先進的な提案が盛り込まれましたが、内容が過度に複雑でブラウザー実装が追いつかず、W3Cはより現実的な方向に舵を切り、当時のブラウザーに既に実装されていた機能を中心に取りまとめた HTML3.2 を1997年に勧告しました。HTML3.0はそのまま破棄されています。3

仕様と実装の混乱

1995年以降のインターネットブームを受けて、HTMLは一般の書籍や雑誌でも取り上げられるようになりました。しかし当時は各ベンダーの独自拡張が先行していたため、解説書にも多くの混乱が見られました。

たとえば、見出し要素 <h1> や <h2> が「文字を大きくするタグ」と説明されたり、段落要素 <p> が「改行して1行あけるタグ」と記述されたりするなど、本来の「文書構造を表す」という意味づけが無視され、ブラウザーのレンダリング結果をそのまま説明にしてしまうケースが目立ちました。また、「タグ」と「要素(エレメント)」という異なる概念を混同して説明する書籍も少なくありませんでした。結果として、初心者は「HTMLとは文字の見た目を整えるための指示書」という誤解を持ちやすく、ウェブの根幹をなす「情報構造のマークアップ」という思想が伝わりにくかったのです。

しかし、1990年代後半から2000年初頭にかけて、すみけんたろう氏や神崎正英氏といった著者たちによって、そうした誤った解釈を是正する書籍も登場しました。45。彼らは「タグ=見た目」ではなく、「要素=意味と構造」であることを丁寧に解説し、またW3C仕様に沿った正しい用語やマークアップの考え方を普及させました。こうした努力により、徐々に「構造とスタイルの分離」という本来の方向性が理解されるようになっていったと感じています。

HTML3.2の時代は、ブラウザーベンダーの独自仕様が追認された混乱期であったと同時に、教育や書籍を通じて「ウェブ標準とは何か」を学び直す時期でもあったと言えるでしょう。そしてその基盤の上に、後のHTML4.0でのStrict/Transitionalの分離や、XHTMLへの流れが築かれていったのです。

HTML4.0 / 4.01 ― 構造とスタイルの分離へ

HTML本来の思想である「構造と表現の分離」に逆行していた HTML3.2の反省を踏まえ、同じ1997年末に策定されたHTML 4.0(および1999年のHTML 4.01)では、大きな方向転換が図られます。文書の論理構造はHTMLで記述し、見た目やレイアウトはCSSで表現するという役割分担が明確に打ち出されたのです6

これを反映して、仕様には以下のようなバリエーションが設けられました。

  • Strict DTD: 構造に特化し、表現に関わる要素を排除
  • Transitional DTD: 過去との互換性を重視し、古い表現用タグも一部許容
  • Frameset DTD: 当時多用されたフレームレイアウト用

つまり「過渡期を支えながら将来的にはスタイルシートに移行する」という方針が公式に示されたのです。これにより、HTMLは構造化文書のための言語としての地位を確立し、CSSがスタイルの主役として台頭する基盤が整いました。

XHTMLへの転換とその挫折

SGMLとHTML ― 「緩い」文法の出発点

HTMLは、SGML(Standard Generalized Markup Language) をベースに設計されました。SGMLは汎用的なマークアップ言語の枠組みであり、HTMLはそのアプリケーションとして位置づけられたのです。SGMLの特徴のひとつは「柔軟さ」で、たとえば次のようにタグの省略が可能でした。

  • <p>要素を閉じなくてもよい
  • <li>要素を連続で書くと自動的にリスト項目として解釈される
  • 属性値にクォーテーションをつけなくてもよい

この「寛容さ」がHTMLを学びやすくした反面、ブラウザー実装の複雑化を招きました。なぜなら、ブラウザーは「壊れたHTML」を修復しながら表示する必要があり、実際に「エラーを許容するパーサー」が暗黙の標準になってしまったからです。

XTHMLへの期待

1990年代後半になると、ウェブは単なる文書配布から「データ交換の基盤」としての利用が注目され始めました。その流れで注目されたのが1998年に勧告された XML(Extensible Markup Language) です。XMLはSGMLを簡略化し、以下のような厳密なルールを採用しました。

  • すべてのタグは必ず閉じる(省略不可)
  • 要素は正しくネストしなければならない
  • 属性値は必ず引用符で囲む
  • 大文字・小文字は区別される

このルールに基づいてHTMLを再定義したのが XHTML1.0 です。これにより、HTML文書をより予測可能で機械処理しやすくし、将来的にウェブとXMLベースの技術(例えばSOAPやWeb Services)を統合しやすくなることが期待されました。

XHTMLの現実

XHTML1.0はHTML4.01と同じ機能を持ちながら文法を厳密化したものでした。DOCTYPEに応じて「Strict」「Transitional」「Frameset」が存在し、開発者は徐々にXML的な書き方へ移行することが推奨されました7

しかし現実には次の課題がありました。

  1. 後方互換性の壁
    • 従来の「壊れたHTML」を多くのサイトが使っており、厳密なXHTMLに移行するコストが高かった。
  2. 実装の中途半端さ
    • 多くのブラウザーはXHTML文書を実際にはtext/htmlとして解釈し、結局HTMLの「寛容パーサー」で処理していた。
    • 真のXMLとして扱うにはapplication/xhtml+xmlを使う必要があったが、これをサポートするブラウザーは少なく、互換性問題を起こした。
  3. XHTML 2.0の失敗
    • 後継として計画されたXHTML2.0は、後方互換性を完全に無視し、廃止要素が多く含まれていた。
    • 代表例として、ウェブの根幹とも言える <img> 要素を廃止し、代わりに <object> を使わせるなど、現場の開発者からは現実離れしていると批判を浴びた8

結果として、XHTML2.0は2009年に正式に破棄され9、開発の中心WHATWGによるHTML5へと移りました。

XHTMLの遺産

XHTMLは普及に失敗したものの、次のような影響を残しました。

  • 厳密な構文チェックの重要性を意識させた
  • XMLの思想は、後にSVGやMathMLのHTML統合という形で部分的に実現
  • 「寛容なHTMLパーサー仕様」を逆に明文化させる契機となった(HTML5では「壊れたHTMLの扱い方」まで仕様化された)

つまりXHTMLは、HTMLの進化において「理想と現実の折り合い」を強く浮き彫りにした存在だったといえます。

HTML5への転換

XHTML 2.0 が頓挫した後、開発者やブラウザベンダーの間では、「後方互換性を維持しつつ、現実的な進化を続けられる HTML 標準」が求められるようになりました。その流れを受けて、HTML5 の仕様策定は次第に WHATWG(Web Hypertext Application Technology Working Group)が主導する形へと移行していきます。

WHATWGの創設とW3Cとの方針の相違

WHATWGはHTMLの現場実装を重視して Apple、Mozilla、Opera の関係者らが中心となって2004年6月4日に設立されました。2007年にはW3CのHTMLワーキンググループが、WHATWGのHTML5仕様を「次の HTML 標準の出発点」として採用する決議を行い、W3C と WHATWG 双方で「HTML5」という名称の仕様を発表するようになりました10。以降、両者は共同である時期は仕様を同じように維持しつつも、運営方針や仕様拡張のスタンスなどで次第に乖離を見せるようになります。WHATWG はバージョン番号を持たず「常に進化し続ける仕様 - Living Standards」を継続的に維持することを目指していたのに対し、W3Cは「HTML5の完成版」を定めたいと考えていたのです。10

最終的な協調

2012年7月、W3C HTMLワーキンググループとWHATWGの仕様運営方針の違いから、両者の HTML5プロジェクトは明確に分岐することになります。W3C は「スナップショット型の標準」を重視し、WHATWGは「リビングスタンダード」の継続を選びました。両者は長らく方針の違いで共同歩調を取れない状態が続きましたが、2019年5月にHTMLとDOMの仕様開発を基本的にWHATWGリポジトリーで統一する方向で協力することが発表されました。これによって、現在はWHATWGがHTML標準の中心的なメンテナーとなり W3Cは共同パートナーの立場となっています11

Living StandardとBaseline

2014年、W3CはHTML5を正式に勧告しましたが、同時にWHATWGは「リビングスタンダード」方式に移行しました。これはバージョン番号を設けず、常に進化する一つの仕様を公開し続けるという考え方で、今日のHTML標準の中心となっています。これは最新機能を迅速に定義できる一方で、「実際にどの機能が安定して使えるのか」が開発者にとって分かりにくい問題も生みました。

そこで登場したのがBaselineです。これは主要ブラウザで一定期間安定して実装された機能を「共通の基準」としてまとめ、開発者が安心して利用できるガイドラインを提供する仕組みです。これは「仕様は常に動き続けるが、実装面では安定した土台を保証する」という新しい標準化の補完的な枠組みといえます。

Baselineの種類と活用方法

Baselineは、Living Standardとして常に進化し続ける仕様の中で「どの機能が主要ブラウザーで安定して使えるのか」を開発者に示す指標です。MDNなどで採用されている区分は、以下の三種類に整理されています。

Baseline: Widely Available

これはすでに主要なブラウザーで長期間安定して実装されている機能を指します。ほぼすべてのモダン環境で問題なく利用できるため、開発者は安心して採用できます。新しいウェブサービスや業務システムの基盤的な実装にも適しており、フォールバックを考慮する必要はほとんどありません。

Baseline: Newly Available

最近になって主要ブラウザーで揃って実装された機能です。最新の環境では使えるようになっていますが、リリースから日が浅いため、古いブラウザーや企業内の長期サポート環境では対応していない場合があります。そのため導入する際は、ユーザー層の利用環境を考慮しつつ、必要に応じてフォールバックや段階的な導入を検討するとよいでしょう。

Limited Available

まだ一部のブラウザーにしか実装されていない、または不完全な機能を指します。実運用で使うにはリスクが高く、実験的な検証や限定的な機能追加にとどめるのが無難です。新しい技術を試しつつ、将来的にBaselineへ組み込まれるのを見越して設計を工夫する、というのが典型的な活用方法になります。

最後に

振り返ってみれば、HTMLは30年以上にわたり「使いやすさ」と「厳密さ」の間で揺れ動きながら進化してきました。HTML3.2の混乱期には、文書構造を無視した誤解が広がり、HTML4.0では「構造とスタイルの分離」という大きな理念が掲げられました。XHTMLは理想を追求するあまり現実との乖離を生みましたが、その経験はHTML5における「後方互換性を尊重しつつ実用的な進化を目指す」という方向性へとつながりました。

現在のLiving StandardとBaselineは、その長い歴史の知見を受け継ぎ、仕様を絶えず更新しつつも、開発者が安心して利用できる安定した基盤を提供する仕組みとして機能しています。これは、ウェブが「誰でも情報を発信し、利用できる」という本質を守るための折衷案であり、標準化の到達点のひとつといえるでしょう。

では、今後のHTMLとウェブ標準はどうあるべきでしょうか。第一に、後方互換性の維持は引き続き不可欠です。世界中の無数のウェブサイトが過去のコードの上に成り立っている以上、急激な断絶は現実的ではありません。第二に、新しい技術の迅速な導入と透明性の高い標準化プロセスが求められます。ウェブはアプリケーション基盤としても社会インフラとしても進化し続けるため、セキュリティやアクセシビリティを重視した仕様改定が不可欠です。第三に、教育と普及活動の重要性は今も変わりません。かつての混乱期に誤解を正してきたように、今後も開発者や利用者が「正しいウェブ標準」を理解し実践できるようにしていく必要があります。

HTMLの歴史は「理想と現実のバランス」を模索し続けてきた過程でした。未来のウェブもまた、その延長線上にあります。私たちはその歴史を学びながら、ウェブが誰にとっても開かれた場であり続けるよう、標準と実装の両面で知恵を積み重ねていくべきでしょう。

  1. Hypertext Markup Language (HTML) (1993, Tim Berners-Lee, CERN)

  2. HTML+ (Hypertext Markup Format) (1993, W3C)

  3. HTML 3.0 Draft (Exprired!) Materials (1995, W3C)

  4. スタイルシートWebデザイン: CSS2完全解説 (1998, すみけんたろう, 技術評論社, ISBN:978-4774106229)

  5. ユニバーサルHTML/XHTML (2000, 神崎正英, 毎日コミュニケーションズ, ISBN:4-8399-0454-5)

  6. Introduction to HTML 4.0 (1998, W3C) で表現(presentational elements)をスタイルシートで置き換える方向性が明言されています。

  7. XHTML™ 1.0: The Extensible HyperText Markup Language (2000, W3C)

  8. Goodbye XHTML2 (2009, Bruce Lawson) で「哲学的には純粋だが、後方互換性を損ないすぎている」と非難されています。

  9. Frequently Asked Questions (FAQ) about the future of XHTML (2009, Philippe Le Hegaret, Ian Jacobs, W3C)

  10. W3C - WHATWG Wiki 2

  11. W3C and WHATWG to work together to advance the open Web platform (2019)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?