Web標準の策定プロセスと仕様の系統

「HTML5 の仕様」と一口に言っても、実際にはどの団体のどの文書を指すのかで中身が変わります。Web の標準は単一の組織が一元管理しているわけではなく、領域ごとに別々の団体が、別々の手続きと文書形式で策定しています。この役割分担と系統を押さえると、MDN の先にある一次情報へ迷わず辿り着けるようになります。

4つの団体と担当領域

主要なWeb標準は、おおよそ4つの団体が分担しています。まず全体像を担当領域で把握します。

ざっくり言えば、マークアップと DOM は WHATWG、見た目（CSS）と多くの Web API は W3C、言語本体は TC39、ネットワーク層のプロトコルは IETF という分担です。境界は完全に排他ではなく、たとえば Web API の多くは W3C と WHATWG が連携しながら定義します。

HTML の系統 — W3C から WHATWG への一本化

HTML の歴史は分岐と再統合のドラマです。年代を追うと系統が見えます。

• 1990年代: HTML は IETF、続いて W3C が策定。HTML 4.01（1999）まで W3C が REC として発行。
• 2000年代前半: W3C は XML ベースの XHTML（さらに XHTML 2.0）へ舵を切る。後方互換を軽視した方向に実装者が反発。
• 2004年: Apple・Mozilla・Opera が WHATWG を結成し、後方互換を保つ「Web Applications」路線で HTML を継続。これが後の HTML5 の母体になる。
• 2007年: W3C が WHATWG の成果を取り込み、HTML5 を W3C 側でも策定開始。ここから2つの HTML 仕様が並走する分裂期に入る。
• 2014年: W3C が「HTML5」を REC として発行。一方 WHATWG は版を切らない Living Standard を維持。
• 2019年: 両者が合意（Memorandum of Understanding）。HTML と DOM の唯一の正本は WHATWG の Living Standard とし、W3C は独自版の発行を停止。W3C はレビューと安定参照（スナップショット）に役割を移した。

つまり現在、HTML を引くべき一次情報は WHATWG の HTML Living Standard ただ一つです。html.spec.whatwg.org が正本で、古い w3.org の HTML5 REC を参照すると、もはやメンテナンスされていない分岐版を読んでしまう恐れがあります。HTML 要素そのものの全体像は HTML（Webページの構造） にまとまっています。

DOM API も同じ経緯を辿りました。かつての DOM Level 1〜3（W3C REC）は、現在 WHATWG の DOM Living Standard に一本化されています。詳細は DOM（HTMLの操作） を参照してください。

CSS の系統 — モジュール分割という設計

CSS は HTML とは対照的に、一貫して W3C の CSS Working Group が策定しています。ただし「CSS3」「CSS4」という単一の巨大仕様は存在しません。CSS2.1 以降、CSS はモジュール（Module）単位に分割され、それぞれが独立して進行します。

CSS（総体）
 ├─ Selectors Level 4
 ├─ CSS Color Module Level 4 / 5
 ├─ CSS Grid Layout Module Level 1 / 2
 ├─ CSS Flexible Box Layout (Flexbox) Level 1
 ├─ CSS Cascading and Inheritance Level 5
 └─ ...（数十のモジュールが各自のレベルで進行）

各モジュールは W3C の標準化トラックを段階的に上ります。文書のステータス表記がそのまま成熟度を表すため、仕様を読むときは冒頭のステータスを必ず確認します。

「CSS3」とは厳密には「CSS Level 3 を持つモジュール群」のゆるい総称であり、Selectors Level 4 のように先行して Level 4 に達したモジュールもあります。そのためバージョン番号ではなくモジュール名とレベルで指定するのが正確です。CSS 全体の役割は CSS（見た目のスタイリング） を参照してください。

ECMAScript の系統 — TC39 の段階プロセス

JavaScript の言語本体は ECMAScript という標準名を持ち、Ecma International の TC39 が策定します。規格番号は ECMA-262 で、毎年版が更新されます（ES2015 以降は西暦で呼ぶ）。注意点として、JavaScript という名称は商標に由来する通称で、規範文書名は ECMAScript です。

TC39 の特徴は、機能ごとに進める明快な 4段階（Stage）プロセスです。

Stage 4 に到達した提案だけが、その年の ECMA-262（例: ES2024）に正式収録されます。つまり「もう使える？」を判断するには、提案がどの Stage にあるかと、各エンジンの実装状況の両方を見ます。言語機能の全体像は JavaScript（ブラウザの動的処理） を参照してください。

ネットワークプロトコルの系統 — IETF と RFC

HTTP・TLS・TCP・URI・QUIC・WebSocket といった通信プロトコルは IETF が策定し、成果は RFC（Request for Comments） という連番文書で発行されます。RFC は番号で固定参照でき、改訂時は新しい番号の RFC が古い RFC を「obsoletes（廃止）」する形で置き換わります。

主要プロトコルの系統を辿ると、Web の通信層の進化が見えます。

• HTTP/1.1: 当初 RFC 2616（1999）。後に RFC 7230〜7235 に分割改訂、さらに 2022年に RFC 9110〜9112 へ再編。
• HTTP/2: RFC 7540（2015）→ RFC 9113（2022改訂）。1本の TCP 接続上で多重化。
• HTTP/3: RFC 9114（2022）。トランスポートを TCP から QUIC（RFC 9000） に置き換える。
• TLS: 1.2 が RFC 5246、1.3 が RFC 8446（2018）。
• URL/URI: 構文は IETF の RFC 3986、ただしブラウザの解析挙動は WHATWG の URL Living Standard が事実上の基準。

HTTP の意味論（メソッド・ステータス・ヘッダ）とバージョン別の転送方式が別 RFC に分かれている点は実務で効きます。多重化やヘッダ圧縮の仕組みは HTTP/2の多重化とHPACKヘッダ圧縮の原理 で詳しく扱っています。

仕様を引くときの判断手順

以上を踏まえると、ある機能の一次情報に最短で到達する手順は次のように擬似コードで表せます。

function 一次情報を引く(機能):
    if 機能 in {HTML要素, DOM, Fetch, URL, Streams}:
        return WHATWG Living Standard
    else if 機能 in {CSS, SVG, ARIA, 多くのWeb API}:
        return W3C のモジュール仕様（ステータスを確認）
    else if 機能 in {構文, 組み込みオブジェクト, Promise}:
        return ECMA-262（TC39 提案の Stage も確認）
    else if 機能 in {HTTP, TLS, URI構文, QUIC}:
        return 該当 RFC（最新の obsoletes を辿る）
    else:
        return MDN で担当団体を確認してから一次情報へ

この振り分けができると、「HTML5 仕様」のような曖昧な参照から脱して、版・ステータス・廃止関係まで正確に把握した上で仕様を読めるようになります。

まとめ — 系統を知ると一次情報が読める

Web 標準は単一の組織ではなく、HTML/DOM の WHATWG、CSS と多くの API の W3C、言語本体の TC39、プロトコルの IETF という4つの系統に分かれています。歴史的には HTML が W3C と WHATWG に分裂し2019年に WHATWG へ一本化された一方、CSS はモジュール分割、ECMAScript は Stage プロセス、HTTP は RFC の改訂連鎖という、それぞれ異なる進化様式を取ってきました。「どの団体の、どの形式の、どのステータスの文書か」を見極める習慣が、二次情報に頼らず一次情報を読み解く力につながります。