まだぼやけているHTML5の将来、WHATWGとの二重管理のジレンマ。W3C TPAC 2015

［ゲストブロガー：矢倉眞隆氏 執筆］2015年10月末に札幌市で開催されたW3Cの年次イベントTPAC。その技術総会を取り上げる連載、後編ではメインセッションの後に行われたブレイクアウトセッションを通じて、HTML5やこれからのWeb標準をどう策定していくのかを紹介します。

（本記事は「ネットの3巨人、村井純氏、ティム・バーナーズ＝リー氏、ヴィントン・サーフ氏が札幌で討論。W3CとIETFの協調を模索するべきではないか？ W3C TPAC 2015」の続きです）

TPACのブレイクアウトセッション

メインセッション後は、ブレイクアウトセッションのスケジュール決めが行われました。

ブレイクアウトセッションは、参加者が気になるトピックを提案し、それについて興味を持った人と議論するアンカンファレンス形式のセッションです。2011年のTPACから導入されて好評を博し、すっかりTPACのおなじみとなりました。

今年はなんと50ものセッションがあったようです。トピックもIoT/WoTやセキュリティ、個々のAPIやW3Cのアクティビティ紹介と幅広くカバーされています。今回は私が参加した2つのセッションの様子をお伝えします。

コミュニティベースで仕様を提案、WICG

Web Platform Incubator Community Group（WICG）という新しいコミュニティグループのセッションでは、グループの議長を務めるGoogleのChris Wilsonと、AkamaiのYoav Weissがグループの目的や今後の展望を紹介しました。

WICGは名前の「インキュベーター」が示唆するとおり、新しい技術の普及について皆で検討し支援するのを目的としたグループです。W3Cのスタッフやベンダーも参加していますが、あくまでコミュニティというかたちで運営されます。

新しいアイデアをWebに持ち込むのは大変です。標準化や実装には時間がかかり、Web開発者一人では到底できることではありません。しかしユースケースは様々で、標準化団体やベンダーがそれに対応するのも不可能です。WICGでは、そういった問題への対策として作られました。

この試みは果たしてうまくいくのでしょうか。わかりませんが、コミュニティ活動の成功例があります。このグループの間接的な前身である、Responsice Images Community Group（RICG）です。RICGはレスポンシブWebデザインでの画像に悩んでいた開発者が集まり、仕様を検討し、ベンダーにも関わってもらい、実装をクラウドファンディングで支援するなどして＜picture＞要素の実現を成し遂げました。

さて、機能の検討や提案はこれまでワーキンググループでも行われていましたが、今後はどのような関係になるのでしょうか。セッションではWeb Platform Working Group（WPWG）との関係も説明されていました。

WPWGはこれまで様々なAPI仕様を策定していたWeb Applications Working GroupとHTML5仕様を策定していたHTML Working Groupが統合したグループです。今後のWebプラットフォームAPI策定をどうするか方針を決める移行期のグループで、来年秋までの活動を予定しています。そのグループ憲章では「新しいAPIの提案はこのグループではなくWICGでの活動を促す」と書かれています。ワーキンググループは既存仕様の策定や今後の方針を、まったく新しい機能の検討についてはWICGをというのが望まれているようです。

もちろん、WICGにすべての提案を集中させる必要はなく、開発者・ベンダーがコミュニケーションをとりながら作業できれば、RICGのように特定のトピック専門のコミュニティグループができるのも構わないとのことでした。

まだぼやけているHTML5の将来

「Future of HTML」と題されたセッションでは、HTML5仕様の現状と今後の方針について共有するセッションでした。人が集まるかなとおもいきや、部屋には20名弱。HTML5仕様が勧告されてから1年経ちましたが、勧告され「完了」と思われたこと、そこから大きな動きがなかったことが、注目を集めなかった理由なのでしょうか。

セッションオーナーはWeb Platform Working Group（WPWG）の議長であるYandexのChaals McCathie Nevileですが、部屋にはHTML Working Groupの議長を務めたMicrosoftのPaul Cottonなども参加し、今後のHTMLを考えるには絶好の機会になりました。

HTML5については過去に「HTML 5.0を2014年に、HTML 5.1を2016年に勧告させる」という計画が発表されていました。しかし、HTML5仕様の勧告作業に時間が取られ並行作業ができなかったこと、またHTML仕様書の管理の複雑さから、この計画は半ば断念したかたちとなっています。

「HTML仕様書の管理の複雑さ」ですが、これはHTML5仕様の大部分がWHATWGのHTML仕様書から生成されていることに起因します。W3Cで管理されているHTML5仕様やCanvas 2D仕様、Web Storage仕様やWebSocket API仕様など多数の仕様は、WHATWG HTML仕様書から切りだされ、その上でW3Cでのコンセンサスを盛りこんだパッチを適用し、W3Cの仕様書として作られています。

こうしたWHATWG HTMLとの二重管理もそうですが、日々更新されるWHATWG HTMLに比べて更新されないHTML5仕様の古さが問題視されていました。ブラウザベンダーの開発者の多くはフィードバックが仕様にすぐ反映されることからWHATWG HTMLや「Living Standard」と呼ばれるモデルを好んでいます。W3Cでも一部の草案はLiving Standardモデルへ移行していますが、HTMLやCSSなどは現時点で古いモデルのままです。

このように手間をかけているW3Cの仕様は必要なのか、という疑問は当然わきます。作業するコストは当然かかりますし、他の仕様にそのリソースを割けられれば良いことに変わりありません。セッションでもその疑問は当然出ていました。

しかしここで懸念されるのが、WHATWGの仕様では明確にされない特許ポリシーです。例えば、CanvasはAppleが特許を保有する技術ですが、Appleはロイヤリティフリーにすることを明言しています。このため他の企業も安心して実装できるわけです。とくに大きな企業にとっては、仕様中の機能が特許ポリシーのもと保護されることは重要でしょう。

WHATWG HTMLも、WHATWGをW3Cのコミュニティグループにすることで解決を試みましたが、うまく運用できてはいません。そのためマイクロソフトなどはWHATWGの仕様には直接的に関与していません。もっとも、マイクロソフトから「EdgeチームもWHATWG HTML仕様を参照しているので、（WHATWG HTMLに）特許ポリシーがあれば…」という発言があったのも事実です。

特許ポリシー、W3CのコンセンサスをすべてWHATWG HTMLに持ち込めないといった課題から、HTML仕様のメンテナンスはW3Cでも続きそうです。しかし仕様書が大きいこともあり、機能ごとにモジュール化したうえで、メンテナンスが必要ないものを削るといった話が出ていました。

WPWGではまだHTMLに対する具体的な計画はでていませんでしたが、HTML5仕様やHTML 5.1の草案をメンテナンスできていない現状はなんとかしたいという発言があったことから、そこまで遠くない時期に何かしらの動きはありそうです。