HTMLやCSS、JavaScriptについて調べていると、かなりの確率で出てくる名前があります。

W3C

MDN

WHATWG

さらにJavaScriptを調べていると、

TC39

ネットワーク関係になると、

IETF

とかも出てきます。

最初の頃は、

「全部公式サイトみたいなもの？」

「MDNがHTMLの仕様を決めてるの？」

「W3CとWHATWGは何が違うの？」

「結局どこを見れば正しいの？」

と、よく分かっていませんでした。

今でもたまに混乱するので、Web開発でよく見るこれらの名前を整理しておきます。

まず結論

かなり大雑把に整理すると、こんな感じです。

つまり、

仕様を作る側

W3C
WHATWG
TC39
IETF

        ↓

仕様を分かりやすく説明する側

MDN

という違いがあります。

MDNだけ少し立場が違います。

W3Cとは？

W3Cは、

World Wide Web Consortium

の略です。

日本語では「ワールド・ワイド・ウェブ・コンソーシアム」などと呼ばれます。

Webを発明したティム・バーナーズ＝リーによって1994年に設立されました。

現在は国際的な非営利組織として、企業、研究機関、専門家などが参加し、Web技術の標準化を行っています。

W3C自身はWeb標準について、

ブラウザや検索エンジン、Webアプリなどを実装するための設計図

のようなものとして説明しています。

例えばW3Cでは、

• CSS

• SVG

• Webアクセシビリティ

• Webフォント

• WebRTC関連技術

• XML

など、多くのWeb技術について標準化活動を行っています。

そもそも「標準化」って何？

これが結構重要です。

例えば、

<p>こんにちは</p>

と書いたとき、

Chromeでは段落になるけど、

Firefoxではボタンになる。

Safariでは画像になる。

となったらWeb開発はかなり困ります。

そこで、

<p>は段落を表す

<a>はリンクを表す

display: flex はこう動く

SVGのcircleはこう描画する

といった共通ルールを決めます。

これがWeb標準です。

ブラウザメーカーなどがその仕様を参考に実装することで、

Chrome
Firefox
Safari
Edge

     ↓

だいたい同じHTML・CSS・JavaScriptが動く

というWebの仕組みが成立しています。

じゃあHTMLもW3Cが決めている？

ここが少しややこしいところです。

昔のWeb開発の知識だと、

HTML = W3C

というイメージが強いと思います。

現在のHTMLの中心的な仕様は、

WHATWGのHTML Living Standard

です。

W3Cの公式ページでも、現在のHTML標準としてWHATWGのHTML Living Standardを案内しています。

WHATWGとは？

WHATWGは、

Web Hypertext Application Technology Working Group

の略です。

名前が長い。

WHATWGは2004年からHTMLの開発を続けているコミュニティです。

現在は、

• HTML

• DOM

• Fetch

• URL

• Encoding

• Streams

• Storage

• WebSockets

など、Webプラットフォームの重要な仕様を開発しています。

W3CとWHATWGは何が違う？

歴史をかなり簡略化すると、

W3C
HTMLを標準化

↓

Webアプリが急速に発展

↓

HTMLをもっと継続的に進化させたい

↓

WHATWGが活動

↓

W3C版HTMLとWHATWG版HTMLが並存する時期が発生

↓

それは分かりにくい

↓

2019年
W3CとWHATWGが協力することで合意

という流れがあります。

2019年にW3CとWHATWGは、

HTMLとDOMについて単一の開発ストリームで協力する

という合意を結びました。

現在、HTMLとDOMは主にWHATWGでLiving Standardとして開発されています。

Living Standardって何？

普通の仕様書というと、

HTML 4
↓
HTML 5
↓
HTML 5.1
↓
HTML 5.2

のようにバージョンが上がっていくイメージがあります。

WHATWGでは、

Living Standard

という方式を採用しています。

Livingは「生きている」という意味。

つまり、

仕様を公開
↓
改善
↓
仕様を更新
↓
新しい機能を追加
↓
問題を修正
↓
さらに更新

と、継続的に仕様を更新していきます。

そのため現在は、

HTML5の次はHTML6なの？

という考え方より、

HTML Living Standardが継続的に更新されている

と理解した方が現在の実態に近いです。

ではMDNとは？

そしてWeb開発をしていると一番よく見るかもしれないのが、

MDN Web Docs

です。

MDNはMozillaが所有・運営する、Web開発者向けのドキュメントプロジェクトです。

HTML、CSS、JavaScript、Web APIなどについて、

• 使い方

• 構文

• サンプルコード

• ブラウザ対応状況

• 注意点

などが開発者向けに整理されています。

例えば、

SVGのcircleってどう書く？

↓

MDNを見る

とか、

fetch()の引数なんだっけ？

↓

MDNを見る

とか、

CSSのgrid-template-columns忘れた

↓

MDNを見る

という使い方です。

MDNは仕様を決めているわけではない

ここは重要です。

MDNが、

HTMLではこうしてください

と独自にルールを決めているわけではありません。

基本的には、

W3C
WHATWG
TC39
など

↓
技術仕様

↓

MDN

↓

開発者向けに整理・解説

↓

自分たち

という位置付けです。

つまりMDNは、

仕様書そのものではなく、仕様を使う開発者向けの実用的な技術資料

と考えると分かりやすいです。

仕様書を直接読めばMDNはいらない？

理論上はそうかもしれません。

でも実際にはかなり厳しい。

例えばHTML Living Standardは非常に詳細です。

当然ですが仕様書なので、

初心者が理解しやすいか

より、

ブラウザ実装者などが
仕様を正確に解釈できるか

が重要です。

実際、WHATWG自身も開発者向けHTML仕様について、正確性や完全性を優先するため、Web技術にある程度慣れていない読者には適さない場合があると説明しています。

そこで普段の開発ではMDNが便利です。

例えばSVGを調べる場合

今回SVGの記事を書くときにも、

W3C

と

MDN

が両方出てきました。

役割としては、

W3C

SVGという技術の仕様
「どうあるべきか」
を定義する


MDN

SVGの使い方
「開発者はどう使うか」
を解説する

という違いです。

なので、

circleの使い方を知りたい

↓

MDN

で十分。

一方、

SVG仕様上circleは
厳密にどう定義されている？

↓

W3CのSVG仕様

となります。

JavaScriptで出てくるTC39とは？

JavaScriptを調べていると、

TC39

という名前も出てきます。

TC39は、

Ecma International Technical Committee 39

のことです。

JavaScriptの正式な標準仕様である、

ECMAScript

を策定・維持している技術委員会です。

例えばJavaScriptに、

async / await

や、

?. 

Optional Chaining、

??

Nullish Coalescing、

などの新しい機能を追加するとき、

TC39で提案・検討が進められます。

JavaScriptとECMAScriptって何が違う？

これも混乱しやすい。

かなり簡単に言えば、

JavaScript
        ↓
言語としての標準仕様
        ↓
ECMAScript

です。

ECMAScriptの仕様は、

ECMA-262

として公開されています。

TC39がこの仕様を継続的に更新しています。

つまり、

JavaScriptを使う

↓

MDNで使い方を見る

↓

さらに仕様を調べる

↓

TC39 / ECMA-262

という流れになります。

IETFっていうのも出てくる

さらにWebSocket、HTTP、TLS、QUICなどを深く調べていると、

IETF

という名前が出てきます。

IETFは、

Internet Engineering Task Force

の略です。

こちらはWebページそのものというより、

Internetを動かす通信技術

の標準化を行っています。

例えば、

• TCP

• HTTP関連技術

• TLS

• QUIC

• DNS

• メール

• WebRTC関連プロトコル

などです。

RFCって何？

IETFを調べると、

RFC 6455
RFC 9110
RFC 8446

みたいな番号も大量に出てきます。

RFCは、

Request for Comments

の略です。

IETFなどがInternet技術に関する技術文書を公開する仕組みです。

例えば、

WebSocket Protocol
↓
RFC 6455

のように、プロトコルの仕様がRFCとして公開されています。

ただし注意点として、

RFCだから全部が「現在の標準」という意味ではありません。

RFCにはStandards Track以外にも、Informational、Experimentalなど複数の位置付けがあります。

また、後のRFCによって更新・置き換えられていることもあります。

一度整理するとこうなる

Web開発でよく見る名前をまとめると、

                   Web技術
                      │
     ┌────────────────┼─────────────────┐
     │                │                 │
    W3C             WHATWG             IETF
     │                │                 │
 CSS・SVG等      HTML・DOM等       Internet通信
                                       │
                                  RFCとして公開


                 JavaScript
                      │
                     TC39
                      │
                  ECMAScript


これらの技術を
開発者向けに分かりやすく説明
                      │
                     MDN

という感じです。

どこを見ればいいの？

普段のWeb開発なら、個人的にはこう使い分ければ十分だと思います。

普通に使い方を調べたい

MDN

まずこれ。

例えば、

CSSの書き方
HTML要素
WebSocket API
SVG
JavaScript
Fetch API

など。

HTMLの正式な仕様を確認したい

WHATWG HTML Living Standard

CSSやSVGなどの仕様を深く調べたい

W3C

ただし技術によって現在の仕様を管理している団体は異なるため、個別に確認します。

JavaScriptの新機能や仕様を確認したい

TC39 / ECMAScript仕様

HTTP、WebSocket、TLSなどプロトコルを調べたい

IETF / RFC

「公式サイト」という言い方にも注意

これを整理していて気付いたのですが、

公式

という言葉も少し雑でした。

例えば、

MDN

は非常に信頼性の高いWeb開発ドキュメントですが、

HTMLの仕様を決定する公式標準化団体ではありません。

逆にWHATWGのHTML Standardは一次資料ですが、普段の開発で毎回読むにはかなり重い。

なので、

一次資料・仕様
↓
W3C / WHATWG / TC39 / IETF

実務向けリファレンス
↓
MDN

くらいに分けて考えると分かりやすいです。

技術記事を書くときはどうする？

ブログで技術記事を書く場合も、この関係を知っておくと便利です。

例えば、

「SVGは拡大しても画質が劣化しにくい」

と書くなら、

MDN
+
W3C SVG仕様

を確認する。

JavaScriptの仕様について書くなら、

MDN
+
TC39 / ECMA-262

を確認する。

WebSocketのプロトコルについて書くなら、

MDN
+
RFC / WHATWG

まで確認する。

このように、

MDNで理解して、必要なら一次資料まで確認する

くらいが現実的だと思います。

最後に

Web開発をしていると、

W3C
WHATWG
MDN
TC39
IETF
RFC

という名前が当然のように出てきます。

最初は全部似たような技術サイトに見えますが、実際にはかなり役割が違います。

一番簡単に覚えるなら、

W3C
Web標準を作る組織

WHATWG
HTMLなどを継続的に開発する

TC39
JavaScriptの仕様を作る

IETF
Internetの通信仕様を作る

MDN
それらを開発者向けに説明してくれる

くらいで良さそうです。

そして普段の開発では、

まずMDNを見る。

より厳密な情報が必要になったら、

元になっている仕様書を見る。

この使い方が一番分かりやすそうです。

これもまた忘れそうなのでメモ。