「Web標準」や「XHTML+CSS」といった言葉がでてくるWeb制作の本には，必ずといっていいほど「W3C」という言葉が登場します。今回はそのW3CというWeb標準化団体について，またW3Cが策定する仕様がどのように作られているのかをとりあげます。

そもそもW3Cって?

W3C（World Wide Web Consortium）とは，Web技術の標準化を行う団体のひとつです。「⁠Webの可能性を最大限に引き出す」ことを目的とし，Webの発明者であるTim Berners-Leeによって1994年に組織されました。W3Cは今日までにHTML（3.2以降）やXML，XHTML，CSSといった，数々の仕様を公開しています。

W3Cには，IT関連企業をはじめとする400近くの会員が参加しています。Apple, Google, Microsoft, Mozilla, Operaといったブラウザベンダーはもちろんですが，中にはBoeingやChevronなど，どのようにWebと関わっているのかが想像できない企業も会員として加わっており，幅の広さを感じます。この多様性が，Webという広大で不定なメディアにおいて，標準化を行うのによい土壌となっているのかもしれません。

W3Cの技術仕様とWeb標準

W3Cではさまざまな仕様が策定され，技術文書（Technical Report）として公開されています。このうち，標準化作業が終了したW3Cの仕様は「勧告（Recommendation⁠）⁠」と呼ばれています。勧告とはISOやJISといった標準規格とは異なり，デファクト標準（事実上の標準）という形式をとっています。この性質上，W3Cの仕様は勧告された時点で利用可能，もしくは既に普及しているものということになります。

デファクトかそうでないかに関わらず，Webに関係する技術のうち標準化されたものを「Web標準 (Web Standards)」と呼びます。しかし一般的には，XHTML，HTML，CSSといった，Webのフロントエンドで使われる技術のうち標準化されたものを，Web標準とすることが多いようです。

なぜ標準化作業が必要なのか

W3Cで策定される仕様には，まったく新しい仕様として作られたものと，すでに普及している技術を標準化して作られたものという，二通りのケースが存在します。

ただ，後者については「すでに普及している技術が『デファクト標準』なわけだから，仕様にする意味はないのでは？」と思われる方もいるでしょう。たしかに，すでに機能しているものをコストをかけて仕様とする必要はあまりないようにも思えます。

しかし，普及している技術において，全ての機能や挙動が細かく定義されているわけではありません。このため，その技術を採用する製品の間で互換性が満足に確保されない状況に陥ることがあります。充分な互換性がなければ，挙動の差異を埋める必要がでてきますから，利用者に負担を強いることになります。互換性を確保するために詳細を記述することは重要なのです。

また，普及しているとはいえ，その技術がプロプライエタリなものであり，特定のベンダーに守られているといった状況であれば，健全な状態とはいえないでしょう。誰もが技術を不都合なく利用できるように，オープンな仕様を策定することも重要でしょう。

互換性を向上させるため，そしてオープンな仕様として仕様とするため。W3Cでは，このようなWeb標準を広めるべく，独自の仕様策定プロセスを用意しています。

勧告までの道のり

W3Cの仕様は，その目的ごとに設立されたワーキンググループ（Working Group, WG）が策定します。W3Cの仕様策定プロセスは，W3C Process Documentの第七章にまとめられています。

仕様はまず，実装されるべき機能やユースケースなどを考えることからはじまります。その後，具体的な詳細を仕様の草案（Working Draft）として公開し，W3C内外を問わず広くレビューを募ります。草案を何度か公開し仕様を練り上げ，要件を満たしたと判断したら，WGは最終案内（Last Call）のアナウンスを行います。

最終案内の期間中は，他のWGなどと協力し，双方の仕様の間に不整合が無いかなどをチェックします。問題がないと判断されたら，その仕様を勧告候補（Candidate Recommendation）として公開し，実装者に実装の呼びかけ（Call for Implementations）を行います。

実装の呼びかけに応じて，実装者は仕様を実装します。仕様に不明瞭な点や，現段階では実現が難しい機能が見つかった場合，それらはWGにフィードバックされます。実装が進み，仕様が持つ機能全てに対し二つ以上の実装が存在すると，その仕様は勧告に向け動き出します。

WGはテストケースを作成し，実装が仕様どおりに実装されているかを確かめます。実装の検証が問題なく終われば，仕様は勧告案（Proposed Recommendation）として公開されます。最後に，W3Cの諮問委員会で審議が行われ，その決議により仕様は勧告として公開されます。

「勧告されてからが実装」と思われている方が多いかもしれませんが，これは正しくありません。昔のW3Cプロセスではそうなっていたのですが，現在は「実装ありきの勧告」となっています。