「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の第七章 にまとめられています。
図1 W3Cの仕様策定プロセスの流れ
仕様はまず、実装されるべき機能やユースケースなどを考えることからはじまります。その後、具体的な詳細を仕様の草案（Working Draft）として公開し、W3C内外を問わず広くレビューを募ります。草案を何度か公開し仕様を練り上げ、要件を満たしたと判断したら、WGは最終案内（Last Call）のアナウンスを行います。
最終案内の期間中は、他のWGなどと協力し、双方の仕様の間に不整合が無いかなどをチェックします。問題がないと判断されたら、その仕様を勧告候補（Candidate Recommendation）として公開し、実装者に実装の呼びかけ（Call for Implementations）を行います。
実装の呼びかけに応じて、実装者は仕様を実装します。仕様に不明瞭な点や、現段階では実現が難しい機能が見つかった場合、それらはWGにフィードバックされます。実装が進み、仕様が持つ機能全てに対し二つ以上の実装が存在すると、その仕様は勧告に向け動き出します。
WGはテストケースを作成し、実装が仕様どおりに実装されているかを確かめます。実装の検証が問題なく終われば、仕様は勧告案（Proposed Recommendation）として公開されます。最後に、W3Cの諮問委員会で審議が行われ、その決議により仕様は勧告として公開されます。
「勧告されてからが実装」と思われている方が多いかもしれませんが、これは正しくありません。昔のW3Cプロセスではそうなっていたのですが、現在は「実装ありきの勧告」となっています。
現実はプロセスをいったりきたり
さて、プロセスの流れだけをみると、勧告まではスムーズに進むように思えます。しかし、このような一本道で仕様が勧告になることはありません。実は、この勧告プロセスには「次の段階へ進む条件を満たせなければ、草案まで差し戻される」という、すこし厳しい条項が設けられているのです。
たとえば、実装者からのフィードバックにより、仕様に足りない部分や変更を行う必要がでてくると、その仕様は勧告候補から草案まで差し戻され、再度WG内で検討されることになります。このコストのかかるプロセスが繰り返されることで、実装に必要な要件や詳細が充実し、仕様の完成度が高められるのです。
また、最近のW3Cは実装同士の互換性（interoperability）に重点をおいています。仕様に曖昧な記述があるなどの理由で、実装ごとに挙動が異なるといった状況が生まれてしまうことがあるからです。というわけで、互換性を高めるために仕様を修正した結果として、仕様が草案に差し戻されるというケースも見られるようになってきました。
おまけ：HTML5やCSS3は今どんな状態にあるのか
ここで、最近公開されたHTML/CSS関連の仕様が現在どんな状態にあるのかを紹介しようと思います。
HTML5 2009年4月に3回目の「草案」が公開されました。最終草案は今年10月という話もありますが、まだまだ解決すべき問題も多く、このとおりに行くかはわかりません。2010年中の勧告というスケジュールがありますが、これは現実的ではありません。
CSS 2.1 2009年4月に「勧告候補」が公開されました。CSS 2.1は2004年に勧告候補となりましたがその後草案に差し戻され、今回の勧告候補は2007年に勧告候補として公開されたものを更新する形で公開されています。プロセスの行き来を繰り返しているため仕様の完成度は高まっており、現在はテストケースの作成など、勧告案に向けた準備を進めている最中です。
CSS3 セレクタ 2009年3月に、「 最終草案」が公開されました。この仕様も2度ほど勧告候補になっていますが、互換性を確保できていない機能を削除するなど、仕様の完成度を上げる活動を行っています。今回の最終草案でほぼ問題は解決したとみられ、今後は順調に勧告へ向け進んでいくものと思われます。
CSS3 フォントモジュール 2009年6月に「草案」が公開されました。それまで別個に存在していた「フォント」仕様の草案と「Webフォント」仕様の草案を統合し、内容を整理しています。草案段階ですが、いくつかの機能については勧告候補を待たずに実装がスタートしています。
CSS3 段組モジュール 2009年6月に「最終草案」が公開されました。今回が初の最終案内となります。こちらについても、部分的な実装があります。
まとめ
W3CはWeb標準と呼ばれる、XHTMLやCSSなどの規格を公開する団体です。業種を問わず多くの企業や学術機関が参加しており、技術仕様を策定し勧告というかたちで公開します。策定する仕様が広く利用されるように、完成度を高めるためのプロセスが用意されています。
