Flexboxの仕様って勧告に至ってないけど使っていいの?迷ったのでW3Cの仕様策定プロセスを読んでみた

Advertisement

この記事の公開時(2016年2月21日)の時点で、Flexboxの仕様のステータスは「W3C Last Call Working Draft 」で、プロセスの第一段階の草案の次のステップでW3Cの承認・推奨を得ていない状態です。このステータスで、これから数年使いたい基盤となるフレームワークなどにFlexboxを使っていいのか?ちょっと迷うところです。

ブラウザサポート は充実してきてますし、Foundation 6 Bootstrap 4(β2 α版 などの主要フレームワークでも採用され始めているし、よっぽどのことがない限り問題はなさそうです。でも、仕様のステータスはちょっと気になります。

そこで、そもそもW3Cの仕様策定プロセス(Development Process)がどんなものか読んで整理してみました。「だいたいこんな感じ」というのは理解していたつもりなんですけど、細かいところまでは把握してませんでした。今回読んでみて思ったんですが、この長いプロセスを経て全ての仕様が作られてることを考えると、W3Cの方々には足を向けて寝られませんね。

結論をサクッと知りたい方へ

[修正: 2016/04/04] 2016年4月4日現在、Flexboxの仕様は勧告候補(Candidate Recommendation)の状態で、勧告(Recommendation)に至るまでにはまだ時間がかかりそうです。ただ、メディアクエリの時がそうだったように、勧告に至っていなくても広く使われ始めるCSSモジュールもあるので、Flexboxは試験的に使ってみて用途の可能性を探る、また、リスクを理解したうえでそろそろ使い始めても良い段階といったところでしょうか?メディアクエリの時のプロセスに当てはめてみると勧告は2017年9月くらいになりそうです。はじめにネタをばらしてしまうと、ドキュメントを読んで、メディアクエリの時のプロセスと比較してみたところ、Flexboxはもしかすると今年中には勧告されるかも?といった感じです!ただ、どんでん返しがないとも限らないので、なんとも言えないというのが正直なところでもあります。

目次

以下は、「W3C Technical Report Development Process 」を読んで、自分なりに解釈してできるだけシンプルに整理した(つもりの)ものです。

プロセスの概要:4つのステップ

W3Cの仕様(Technical Report)が形作られ、W3Cの承認を得て正式に勧告されるまでには、大きく分けて4つのステップがあります。

w3c-tr-dev-process-chart
  1. 草案(Working Draft / WD)
  2. 勧告候補(Candidate Recommendation / CR)
  3. 勧告案(Proposed Recommendation / PR)
  4. 勧告(Recommendation / REC)

ざっくりと、以下のようなプロセスで策定が進められます:

  • ワーキンググループが作った草案が何回かの編集プロセスを経て仕様のスコープが洗練されていきます。
  • その後のレビューでW3Cの条件を満たしていると判断された場合、勧告候補のステップに進みます。
  • 勧告候補の段階では、ワーキンググループがスペックの実装を検証する一方で、スペックが勧告としてふさわしいものかW3Cメンバーが検証しフィードバックします。
  • 次の勧告案のステップでW3Cメンバーのレビューが完了されます。
  • その後、ディレクターが承認しW3C勧告となります。

仕様策定に関わる人々と権限

仕様策定について知るには、W3Cの誰が何を担当し、どのような権限持っているかを知っておく必要がありそうです。ただ、なかなか登場人物が多いので、仕様策定がどのように行われているかを理解するために、僕が必要最低限と考える情報をまとめてみます。

W3Cメンバー

まず、W3Cメンバーになるには組織での登録申請 が必要で、各メンバー組織から選ばれた代表者1人からなる諮問委員会(Advisory Committee )を組織します。この諮問委員会がディレクターからの宣言書(Charter)、勧告案、プロセス・ドキュメント案の提案をレビューします。

ちなみに、諮問委員会は以下も行います:

  • W3Cのプランのレビュー
  • 議長以外のアドバイザリー・ボード(Advisory Board )メンバーの選出
  • 9人中、5人のTechnical Architect Groupメンバーの選出

W3Cチーム

W3Cチームは以下のメンバーから組織されます。W3Cチームが仕様策定を先導しウェブやW3Cの技術について一般の人々とメンバーとコミュニケーションを行います。

  • ディレクター
  • CEO
  • W3Cスタッフ(有償)
  • インターン(無償)
  • W3Cフェロー(メンバー組織の社員)

ディレクター

ディレクターはW3Cのリード・テクニカル・アーキテクト(Lead Technical Architect) — Tim Berners-Lee氏。ディレクターは他のメンバーに権限を委譲して良いとあるので、彼が全ての仕様に目を通すというより、ディレクター代理の方々が実際の多くの業務を担っていると想像します。

ディレクターは、仕様の次のステップへの移行を拒否する権限があり、さらに、前のステップに戻すこともできます。ディレクターが最大の権限を持ち、ディレクターが問題だと認識した場合は勧告には至らないわけですね。

ワーキンググループ

ワーキンググループは以下のメンバーから組織されます。W3CメンバーとW3Cチームの意向によりワーキンググループの宣言書(目的や主義を記したもの / Charter)が作られ、諮問委員会とディレクターのレビューを経てワーキンググループが作られます。

  • メンバー組織の代表者
  • 招待されたエキスパート(招待条件やプロセス を満たす必要あり)
  • W3Cチームのメンバー

ちなみに、FlexboxはCSSワーキンググループ によって作られているものです。

その他の組織ユニットの役割

アドバイザリー・ボード(Advisory Board)

アドバイザリー・ボード は決定権を持たず、役割は厳格に助言のみと定められています。あくまで、運営をスムーズに行うための相談役といった位置付けのようです。

テクニカル・アーキテクト・グループ(Technical Architect Group / TAG)

選出または任命された参加者と議長(Chair)からなる9名のグループ。ウェブの設計の管理を担う。あくまで技術的な要素を扱うグループで、W3Cの組織的なことには関与しないとのことです。議長以外は2年の任期で、TAGのページ を見ると、現在、Chairは3人いるんですね。Process DocumentのTAGセクション を読む限り、TAGに仕様策定における決議権はなさそうです。

ただ、以下の役割を担うので、仕様策定にかなりの影響を与えると想像します:

  • ウェブのアーキテクチャの原則についての合意形成と文書化を行い、必要に応じてそれら原則を通訳・明確化する
  • TAGに持ち込まれたウェブのアーキテクチャに関わる課題の解決
  • W3Cの内外でのクロス・テクノロジーな設計開発を支援、コーディネートする

仕様の成熟レベル

仕様策定ステップを意訳して簡単にまとめると以下のようになります。

草案(Working Draft / WD)

  • W3Cメンバーを含むコミュニティ、一般の人々、その他の技術組織のレビュー対象としてワーキンググループが発行するもの
  • ワーキンググループ内で同意に至ったものとは限らない
  • 仕様としてW3Cの承認を得たものではなく、勧告に至るとは限らない

勧告候補(Candidate Recommendation / CR)

  • ワーキンググループが指定した技術的要求を満たしたもの
  • すでに広くレビューを終えたもので、より広くコミュニティ内で最終レビューを行うべきとされたもの
  • 諮問委員会の正式なレビューを開始し、勧告、更ならる作業が必要、放棄するなど、次のステップの判断を行う
  • 勧告として承認できるものでなくてはならい
  • 「Last Call Working Draft」と一致する(ちょっと意味が理解できませんでした。。。 [修正: 2016/04/05] この記事での説明は、2015年9月1日版のプロセスドキュメント をベースとしているのですが、2005年版のプロセスドキュメント にある「Last Call Working Draft」と一致するということのようです。)

勧告案(Proposed Recommendation / PR)

  • W3CディレクターにW3C勧告にする十分なクオリティがあると認められたもの
  • これにより諮問委員会に対するレビューの締め切りを確立することになる
  • 本質的な改変は認められない
  • 本質的な改変が必要な場合、新しく草案か勧告候補の作成が必要

勧告(Recommendation / REC)

  • W3Cメンバーとディレクターに承認を得た仕様またはガイドライン・要求書
  • ウェブ標準として広く展開されることを推奨する

メディアクエリの場合

参考までに、2012年6月に勧告に至ったメディアクエリの時はどのようなプロセスだったか見てみます。

2001年4月4日 第一草案発行
2001年5月17日 草案(WD)
2002年1月23日 草案(WD)
Last Callレビューが2月20日まで
2002年7月8日 勧告候補(CR)
少なくともCRの期間は6カ月(2002年7月-2003年1月)と書いてあります。
2007年6月6日 勧告候補(CR)
何か問題があったのか、5年近く経ってもう一度CRが発行されています。ここでは、少なくともあと3カ月(2007年9月まで)はCR期間が必要と書かれています。
2008年10月15日 草案(WD)
ここで一度、草案に戻ってしまったんですね。Last Call Working Draftとあって、11月21日がコメントの締め切りと書いてあります
2009年4月23日 勧告候補(CR)
少なくとも6カ月(2009年10月23日まで)はCR期間が必要とある。CR期間を終えたら実装レポート(Implementation Report)が発行されるとあります。
2009年9月15日 勧告候補(CR)
4月23日版と同じように「少なくとも6カ月(2009年10月23日まで)はCR期間が必要」と書いてあるけど、これは間違いかな?6カ月だったら日付が間違ってるので。
2010年7月27日 勧告候補(CR)
少なくとも4週間(2010年8月24日まで)CR期間が必要と書いてあります。
2012年4月26日 勧告案(PR)
コメントは5月23日までとなっています
2012年6月19日 勧告(REC)

実に10年以上のプロセスを経て仕様の勧告までに至っているのがわかりますね。また、勧告候補になってからも次の発行まで5年も経っていたり、草案に戻ったりもしています。勧告案からは予定通りに勧告に至っているようなので、勧告案になればもう安心といったところでしょうか。

Flexboxの場合

Flexboxは、2009年7月23日に最初の草案(W3C Working Draft)が発行され、その後、草案の改定が4回(2011年3月22日、2011年11月29日、2012年3月22日、2012年6月12日)行われています。

これらの草案改定を経て、2012年9月18日に一度、勧告候補になっています。

その後に、2014年3月25日と9月25日に草案が発行されていて、最新バージョンの「Last Call Working Draft 」が2015年5月14日に発行されています(2016年2月21日現在)。その後、2回の勧告候補を経て2017年10月19日の勧告候補に至っています(2017年12/29日現在)。

2009年7月23日 第一草案(WD)
2011年3月22日 草案(WD)
2011年11月29日 草案(WD)
2012年3月22日 草案(WD)
2012年6月12日 草案(WD)
2012年9月18日 勧告候補(CR)
2014年3月25日 草案(WD)
メディアクエリと同様に一度草案に戻っちゃいましたね
2014年9月25日 草案(WD)
Last Call Working Draftとあって、10月25日がコメントの締め切りと書いてあります
2015年5月14日 草案(WD)
2015年6月11日までコメントを受け付けると書いてありますね。
2016年3月1日 勧告候補(CR)
2016年5月26日 勧告候補(CR)
2017年10月19日 勧告候補(CR)

[追記: 2017/12/29 / 修正: 2017/12/31]
メディアクエリの時と同じような期間を要するとすると、flexboxが勧告案(PR)になるのは2019年の半ば、それから勧告までには数ヶ月として2019年9月とか10月には勧告されているかもしれませんね。それより早まることはないのでしょうか。。。

編集者の草案(Editor’s Draft)

2016年1月5日付で編集者の草案(Editor's Draft)として勧告候補 が存在します。現在、勧告候補を準備中ということでしょうか?

ちなみに、この文書はW3C勧告にする意図があり、2016年5月31日まで勧告候補のステータスを維持すると書いてあります。ということは、Flexboxは2016年6月には勧告から一歩手前の勧告案にステップアップして、勧告までの締め切りが定められるということですかね。

さいごに

メディアクエリは勧告までに10年以上もかかっていたなんて驚きですね。
メディアクエリの時は勧告案から数ヶ月で勧告に至っていることから、もしかするとFlexboxは今年の後半には勧告に至るかもしれませんね!勧告に至った技術の方が安心して心置きなく使えますし、楽しみですね。(マニアックな喜び…)

[修正: 2016/04/04]
メディアクエリの場合は勧告候補(CR)が3回ほどリリースされていて、PRになるまでに1年3カ月ほどかかっています。Flexboxも勧告案(PR)に至るまでに1年超、それから数カ月かかって勧告に至ると考えると2017年9月くらいの勧告が妥当な予測でしょうか?

勘違いしてぬか喜びに終わってしまいましたが、メディアクエリの場合も勧告に至る前に広まっていたので、Flexboxもぼちぼち使い始めることを考えても良さそうだ…と言ったところでしょうか?ただし、仕様変更の可能性がゼロではなくリスクを伴うので、現段階ではあくまでオプション的な使い方に留めておくのが良さそうです。この記事の公開後の3月1日に最新版の仕様がリリースされていて、少なくとも9月1日までは勧告候補(CR)に留まるとあるので、またその頃に状況が見えてきそうです。半年先か。。。

Twitterでご指摘いただき、修正しました!ご指摘ありがとうございました!

About the author

Rriverの竜(りょう)です。「明日のウェブ制作に役立つアイディア」をテーマにこのブログを書いています。アメリカの大学を卒業後、東海岸のボストン近郊でウェブ制作を開始。帰国後、東京のウェブ制作会社に勤務。現在は組織のウェブ担当者として日英バイリンガルウェブサイトの運営に携わっています。より詳しくはこちら

記事へのコメントはもちろん、執筆・翻訳、レスポンシブなウェブサイト制作、コラボのご相談などもTwitter @rriver またはFacebook でお気軽にご連絡ください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です