Plan 2014 ― HTML 5.1とか拡張仕様とか

W3C HTML

ひゃっ、HTML 5.1ときましたか。

2014年に勧告するためにはどうすればいいかあれこれ考えて、「HTML 5.0を2014年に、HTML 5.1を2016年にそれぞれ勧告する」という計画が提案されたと。まだ提案段階なので、決定事項ではない。

要約はChairのひとがしてくれている。こんな感じかな。

  • Charterを改定して、HTML 5.0を2014Q4に、HTML 5.1を2016Q4に勧告するということを書く
  • CR exit criteriaに沿って、テストが必要だと思われる機能のテストに集中する
  • 他との折衝も考えつつモジュールの考え方を導入し、仕様の大きさと複雑さを抑える

さて、どういう意味だろう。

HTML 5.1

いまHTML5にあるもので、安定度の高いものや特に議論が起こってない機能は「HTML 5.0」とする。で、そうでない機能は「HTML 5.1」として作業していくと。HTML 5.0は今年中のCRを、HTML 5.1は今年中のFPWDを予定している。

Issueになって膠着状態にある機能については、その部分を拡張仕様としてまず分離し、その仕様のCR exit criteriaが達成されれば、メインのHTML仕様に統合されると。

で、もしHTML 5.1のタイムフレームにもあわない機能が出てきたら、2015年にHTML 5.2が…という話も。

ここら辺は、CSS 2.1の作業中に安定性に乏しい機能がCSS3に、CSS3ではCSS4に送られるのと似ている。拡張仕様のくだりについても、css3-textなどはいろいろ分離されたりしているし、CSSを参考にしているのかな。

PermissiveなCR exit criteria

「各機能について相互運用可能な独立した実装を2つ」という、いろいろ使われているこのcriteriaだけど、真面目にやるとHTML5のように機能の多い仕様ではとてつもなく時間がかかる。たぶん、CSS 2.1以上にかかってしまう。でもそれは、早い勧告が望まれてる状況ではちょっと許容できない。

というわけで、なんというか、すこし易しいものが提案されている。新しいもののドラフトが先週Maciejからpublic-htmlに投げられている。

その中に“judgement level”なる一節がある。

judgment level

For features that are well known to be widely implemented and deployed, the Working Group will assume effective real-world interoperability without testing. For features that are known not to be implemented at all, or unlikely to have multiple implementations during the CR period, the Working Group will not invest significant effort in testing. For features where the interoperability level is uncertain, the Working Group will create a sufficient test suite to make a judgment call; 100% pass rate will not necessarily be required. In any case where the judgment is debatable, it will be a Working Group decision whether sufficient interoperability has been achieved.

大雑把に訳すと「すでに実装されてて使われているものについては、現実的な相互運用性が担保されてると考える。実装されてる気がしないもの、CR期間中に実装される可能性がないものについては、テストに時間を割かない。相互運用性が不明な機能について、充分なテストを用意し、judgement callを行う。100％のパス率は必要としない。議論の余地がある場合は、WGのdecisionがくだされる。」といったところかなあ。

テストする機能を減らすために考えられたものだけど、実装可能性の薄いものはテストしないとか、そこらへんは現実的でよいのかなあと。ただ、“widely implemented and deployed” の基準はどうするんだろう。結局細かいところでテストスイートを作るはめになるんじゃないかなあという気もする。

拡張仕様とモジュール

これ、これまでもHTML5から分離されたものや、HTML5と関わるような仕様はあった。それらはHTML5の拡張仕様と呼んで、モジュール的なアピールをしているというだけの話ではある。

で、controversialなものがあれば、それを拡張仕様として分離し、独自のペースで作業させると。これはMicrodataやCanvas 2D Contextみたいな前例もあるし、そんな新しいことでもない。ただ、Issueとなっている機能が分離されるとなると、その機能の小ささに面食らうというか「話こじれてるだけじゃん」的な印象をもたれるんじゃないかなあと。hgroupやlongdescだけの仕様ができてもねえ。

どうなるんだろう？

どうなるんだろう。仕様の数が増えて参照がめんどくなる、って以外は、そんなにシビアに変わらないと思いたいけれど。