閉じる

W3CとWHATWGの役割と対立の歴史：HTML/DOM標準化の変遷と現状を解説

広告

現代のWeb開発において、ブラウザ間の互換性が保たれ、同じコードで同じようにページが表示されるのは、Web標準化団体による多大な貢献があるからです。

かつてブラウザ間の仕様の乖離に苦しんだ時代を経て、現在はHTMLとDOMの仕様を一本化する体制が整っています。

本記事では、Web標準化を牽引する2つの組織、W3CとWHATWGの役割と、長年にわたる対立、そして和解に至った歴史的背景を詳しく解説します。

目次 [ close ]
  1. W3Cの役割と組織の成り立ち
    1. W3Cの基本構造と標準化プロセス
    2. W3Cが提唱した「XHTML」という理想
  2. WHATWGの誕生と設立の背景
    1. 設立のきっかけとなった2004年の決裂
    2. WHATWGの哲学：プラグマティズムとスピード
  3. 二つの団体の対立と「HTML5」の誕生
    1. HTML5の開発主導権の変遷
    2. 二つの「HTML5」が存在した混乱期
  4. 2019年の歴史的合意：関係の正常化
    1. 合意の主な内容
  5. 現在の標準化フローと開発者への影響
    1. 現代の仕様策定サイクル
    2. 開発者が意識すべき点
  6. Web標準の未来と新たな課題
    1. ブラウザエンジンの多様性の低下
    2. 進化し続けるWebプラットフォーム
  7. まとめ

W3Cの役割と組織の成り立ち

W3C (World Wide Web Consortium) は、Webの生みの親であるティム・バーナーズ=リー氏によって1994年に設立された、世界で最も権威のあるWeb標準化団体です。

Webの長期的な成長と、あらゆるデバイスやユーザーが等しく情報にアクセスできる「Webの普遍性」を維持することを目的としています。

W3Cの基本構造と標準化プロセス

W3Cは、企業、政府機関、教育機関、そして個人などの会員で構成される国際的なコンソーシアムです。

特定の企業に依存しない中立性を保ちながら、アクセシビリティ、セキュリティ、プライバシー、国際化といった多岐にわたる分野の標準策定を行っています。

W3Cの標準策定プロセスは非常に厳格であり、以下のステップを経て「W3C勧告 (W3C Recommendation)」へと至ります。

  1. 草案 (Working Draft)：技術的な議論の初期段階
  2. 候補勧告 (Candidate Recommendation)：実装のテストが求められる段階
  3. 勧告案 (Proposed Recommendation)：最終的な承認を待つ段階
  4. 勧告 (Recommendation)：公式な標準として認められる段階

このプロセスは合意形成を重視するため、非常に時間がかかるという側面を持っています。

これが後に、開発スピードを重視するブラウザベンダーとの対立を生む要因の一つとなりました。

W3Cが提唱した「XHTML」という理想

2000年代初頭、W3CはWebの未来をXML (Extensible Markup Language)にあると考えていました。

HTMLをXMLの文法で再定義した「XHTML 1.0」を策定し、さらにその進化形として、HTMLとの互換性を捨ててでも厳密な構造を目指した「XHTML 2.0」の開発を進めました。

しかし、この厳密さは実際のWeb開発の現場とは乖離していました。

わずかな記述ミスでページが全く表示されなくなるというXHTMLの仕様は、既存のHTML資産を抱える開発者や、エラーに対しても寛容に表示を行うブラウザの性質とは相容れなかったのです。

WHATWGの誕生と設立の背景

W3CがXHTMLという「理想」を追求する一方で、現実に即したWebの進化を求めたのが、Apple、Mozilla、Operaといったブラウザベンダーの有志たちでした。

設立のきっかけとなった2004年の決裂

2004年に開催されたW3Cのワークショップにおいて、ブラウザベンダー側は「既存のHTMLを拡張し、Webアプリケーションを開発しやすくするための新機能」を提案しました。

しかし、W3Cはこの提案を否決し、あくまでXHTML路線を継続することを決定しました。

これに反発したブラウザベンダーたちは、W3Cの枠組みを飛び出し、独自の標準化団体である「WHATWG (Web Hypertext Application Technology Working Group)」を設立しました。

WHATWGの哲学：プラグマティズムとスピード

WHATWGの最大の特徴は、「実際にブラウザで動作し、利用されている実装」を最優先する点にあります。

W3Cが合意形成と文書化を重視するのに対し、WHATWGは「動くコード」と「後方互換性」を重視しました。

また、WHATWGは「Web標準は完成するものではなく、常に進化し続けるものである」という考え方に基づき、バージョン番号を廃止した「Living Standard (リビングスタンダード)」というモデルを採用しました。

これにより、新しい技術や仕様の変更を即座に標準へ反映させることが可能になりました。

二つの団体の対立と「HTML5」の誕生

WHATWGが策定を進めた「Web Applications 1.0」という仕様は、後に私たちがよく知る「HTML5」の原型となります。

皮肉なことに、W3Cが推進していたXHTML 2.0は普及せず、開発者たちの支持はWHATWGのHTML5へと集まっていきました。

HTML5の開発主導権の変遷

2007年、W3CはついにXHTML路線の失敗を認め、WHATWGのHTML5仕様をベースに新しいHTMLワーキンググループを立ち上げることを決定しました。

ここから、W3CとWHATWGが共同でHTML5を策定するという奇妙な協力関係が始まります。

しかし、この協力関係はスムーズなものではありませんでした。

項目W3CのスタンスWHATWGのスタンス
目標バージョンを固定した「勧告」の完成常に更新される「Living Standard」の維持
意思決定メンバー間の合意 (コンセンサス)エディタによる最終決定と実装重視
対象すべてのステークホルダー (政府、企業、障害者)ブラウザ開発者およびWeb開発者

二つの「HTML5」が存在した混乱期

2012年、両団体の意見の相違は決定的となり、HTML5の仕様を別々に管理することを発表しました。

  • W3C版 HTML5：静的な「スナップショット」としての仕様書。特定の時点での安定性を重視。
  • WHATWG版 HTML Living Standard：動的に更新され続ける仕様書。最新のブラウザ機能を即座に反映。

この結果、開発者は「どちらの仕様書を参照すべきか」という混乱に直面することになりました。

同じタグであっても、W3CとWHATWGで定義が微妙に異なるという事態が発生し、Webの相互運用性を守るはずの標準化団体が、逆に分裂を招くという皮肉な状況が数年間続きました。

2019年の歴史的合意：関係の正常化

長らく続いた二頭体制による混乱に終止符を打つため、2019年5月、W3CとWHATWGはついに歴史的な合意に達しました。

両団体は「HTMLとDOMの仕様をWHATWGのLiving Standardに一本化する」という覚書 (Memorandum of Understanding) を締結したのです。

合意の主な内容

この合意により、現在および将来のWeb標準化における役割分担が明確に定義されました。

  1. HTMLとDOMの開発主体はWHATWGとする：W3Cは独自のHTML仕様を策定せず、WHATWGのLiving Standardをそのまま採用する。
  2. W3Cは「勧告」プロセスを継続する：WHATWGの仕様を定期的に「W3C勧告」としてレビュー・承認し、安定版としてのステータスを与える。
  3. コミュニティの統合：開発者や企業は、主にWHATWGのプラットフォーム上で議論を行い、W3Cはより広範なアクセシビリティやプライバシー、国際化などの専門領域で知見を提供する。

この合意は、事実上のWHATWGによる完全勝利とも評されましたが、実際にはWebの分断を回避し、一貫した開発環境を整備するための、現実的かつ建設的な決断でした。

現在の標準化フローと開発者への影響

2019年の合意を経て、現在のWeb標準化プロセスは非常に効率的かつ透明性の高いものへと進化しています。

2026年現在、私たちが利用しているHTMLはすべてこの新しいプロセスに基づいています。

現代の仕様策定サイクル

現在のHTML/DOM開発は、GitHubを中心としたオープンな環境で行われています。

  1. 提案：新しい機能や改善案がWHATWGのGitHubリポジトリにIssueとして提出される。
  2. 議論と実装：主要なブラウザベンダー (Google, Apple, Mozilla, Microsoftなど) がその機能の有用性と実装の可能性を議論する。
  3. プロトタイプ：少なくとも2つの異なるブラウザエンジンで試験的に実装され、相互運用性が確認される。
  4. Living Standardへの統合：十分なテストと議論を経て、仕様書に正式に追加される。

開発者が意識すべき点

現在の開発環境において、HTML5.2やHTML5.3といったバージョン番号を意識する必要はほとんどありません。

参照すべきは常に「HTML Living Standard」であり、ブラウザがどの機能をサポートしているかは、Can I use...などの外部サービスやMDN (Mozilla Developer Network) を通じて確認するのが一般的です。

また、W3Cが役割を終えたわけではない点も重要です。

W3Cは以下の分野で引き続き強力なリーダーシップを発揮しています。

  • WCAG (Web Content Accessibility Guidelines)：Webアクセシビリティの国際基準
  • CSSの標準化：レイアウトや装飾に関する膨大な仕様の管理
  • WebAssemblyやWebGPU：次世代のWebパフォーマンス技術
  • プライバシーとセキュリティ：Cookieの代替技術や認証API (WebAuthnなど)

Web標準の未来と新たな課題

W3CとWHATWGが手を取り合ったことで、Webの進化スピードは劇的に向上しました。

しかし、新たな課題も浮き彫りになっています。

ブラウザエンジンの多様性の低下

現在、市場にある主要なブラウザの多くがChromium (Blinkエンジン)をベースとしています。

Google Chrome, Microsoft Edge, Opera, Vivaldiなどがこれに該当します。

一方で、独自のエンジンを持つのはAppleのSafari (WebKit) とMozillaのFirefox (Gecko) のみとなっています。

WHATWGの意思決定プロセスは「実装」を重視するため、圧倒的なシェアを持つChromiumが先行して実装した機能が、事実上の標準 (de facto standard) になりやすいという懸念があります。

標準化団体は、特定の企業によるWebの私物化を防ぎ、真の相互運用性を維持するという、より難しい舵取りを求められています。

進化し続けるWebプラットフォーム

Webはもはや単なる文書閲覧のツールではなく、高度なアプリケーション実行環境へと変貌を遂げました。

VR/ARを実現するWebXR、機械学習をブラウザで行うWebNNなど、これまでOSのネイティブアプリでしか不可能だったことが、Web標準として次々に定義されています。

これらの複雑な技術を、どのようにして「安全に」「誰にでも使いやすく」標準化していくかが、今後のW3CとWHATWGの共通の命題となっています。

まとめ

Web標準化の歴史は、「理想を掲げるW3C」と「現実を重視するWHATWG」の対立と融合の歴史でした。

XMLベースの厳格なWebを目指したW3Cの挑戦は失敗に終わりましたが、その高い志はアクセシビリティやセキュリティといったWebの根幹を支える倫理観として今も息づいています。

一方、WHATWGがもたらした「Living Standard」という概念は、技術の激しい変化に対応するための不可欠な仕組みとなりました。

2019年の合意によって両者の役割が整理されたことで、Web開発者はかつてのような仕様の分裂に悩まされることなく、安心して最新技術を活用できるようになったのです。

私たちが日々当たり前のように利用している<div>や<a>といったタグ一つひとつに、こうした情熱的な議論と歴史が刻まれていることを知ることは、より深いレベルでWebというプラットフォームを理解する第一歩となるでしょう。

クラウドSSLサイトシールは安心の証です。

URLをコピーしました！