仕様書の必要は

“Interoperability”

相互運用性

Without this we’re screwed. Remember the browser wars

スペックはどこから？

• インプリメンタ（作成者）
• W3C（例えば、CSS作業グループ）
• 当事者：私達もありえる

All three groups should be involved in a spec’s development

W3C仕様書のステージ

1. 下書き：Editor’s Draft (ED)
2. 草案：Working Draft (WD)
3. 最終草案：Last Call Working Draft (LC, LCWD)
4. 勧告候補：Candidate Recommendation (CR)
5. 勧告案：Proposed Recommendation (PR)
6. W3C勧告：Recommendation (REC)

(Ref)

W3C仕様書のステージ

W3C勧告 ＝ 仕様書 ＝ スタンダード

下書き　Editor’s Draft (ED)

• だれでも書けるが、まだ正式な裏付けはない
• 正式になって、下書きはスペックの最新バージョン

→ Exploring

草案　Working Draft (WD)

• ワーキンググループから賛成
• スペックを書いたり、フィードバックを貰ったり、問題を直したりの作業
• （最初のリリースは「First Public Working Draft (FPWD)」）

→ Design phase

最終草案　Last Call Working Draft (LC, LCWD)

• もうそろそろ出来たら、フィードバックお願い
• 問題を修正する期限を決める

→ Transition

勧告候補　Candidate Recommendation (CR)

• テストの作業（私達だ！）
• その勧告に興味があるインプリメンタは作業を始める
• 仕様策定者は新しい問題を直す
• スペックに「CR Exit Criteria」が書いてある

→ Test, implement, refine

勧告案　Proposed Recommendation (PR)

ここまですれば、

• ２つの別々、正しいインプリメンテーションが必要
• エディターは全部の問題を確認した
• テストも必要

→ Transition

W3C勧告　Recommendation (REC)

• レコメンデーションまで行けば、W3CのAdvisory Committeeは確認の必要
• 小さい修正だけ

→ Maintenance

スペックの一覧

http://www.w3.org/TR/…

TR = Trash

古くさいのスペックご注意！

基本

• 草案（Working Draft）：スペックをデザインする
• 勧告候補（Candidate Recommendation）：テスト、実施
• W3C勧告（Recommendation）：メンテナンス

WHATWG “Living standard”

• 「生きている仕様」：この段階は同じドキュメントにあります：http://whatwg.org/C/
• CSSWGの場合：http://dev.w3.org/csswg/

WHATWG doesn’t make separate versions of a spec based on those stages. No confusion about which version to look at.

WHATWG “Living standard”

1. Idea; yet to be specified
2. First draft
3. Working draft
4. Last call for comments
5. Awaiting implementation feedback
6. Implemented and widely deployed

(Ref)

However, WHATWG follows a similar process, just on a per-feature level, and all in the same document.

W3Cスペックのあり方

• 実施とテストの作業に問題が良く見つかる
• 前か次の段階、どちらも行ける
• スペックは分かれたり、集まったり、もうそのまま放っておかれる場合もありえる

例：Flexbox

例：Flexbox

CRでも最新じゃない

WDは全然違います

「TR = Trash」を忘れないでね！

→ Talk about how ED/WD is like the develop branch of a repo, with CR like a release branch and REC like a tag. The most up-to-date version is develop.

テストの歴史

• テストは（ほぼ）無かった
• スペックは適当、例えばHTML5前にエラーの動きを書かなかった
• インプリメンタはそれぞれ解釈する → 私達に問題
• インプリメンタは自分のテストを作った → 重複

なぜテストを作る？

• インプリメンタは当たった確認
• デヴェロパーに相互運用性
• スペックの仕様策定者にも確認
• W3Cはテストスイートを使って、インプレメンタレポートを作る
• ウェブプラットフォームはもう広すぎる：テストは必要

テストの
ライフサイクル

• スペックはあまり変わらなくなって、テストを作り始め（勧告候補ぐらい）
• 作ったテストを確認後に、W3Cのテストスイートに入れる
• スペックが変わったら、テストも変わる

テストの作り方

• テストは１つだけの事に作る
• テストはシンプルに
• 出来れば、「TestHarness.js」に自動で動くように

テストは足りなかったら…

• スペック問題は見つけない → 直さなかん
• ブラウザー問題も出る → ブラウザーバグ、相互運用性の問題
• 最近、テストが足りなかったら、勧告候補から勧告案に行けない

テストが足りない例

CSS3 Transitions vs Rodney Rehm

ロッドニーさんはCSSアニメーションのスペックを細かくテストして、いろんなブラウザーバク、スペック問題、相互運用性問題を見つけた。

彼のテストはテストスイートに入っていて、そして、バグリポートとスペック修正も出ます。

→ Talk about Rodney Rehm turning over the stone of CSS Animations plus JS, and finding a lot of creepy-crawlies

テストが足りない例

“CSS3 Transitions: Thank God We Have A Specification!” by Rodney Rehm

なぜ？

私に「相互運用性」は１番大事

• テストがあれば、相互運用性は上がります
• 相互運用性はデヴェロパーに助かる

これからどうする

• 明日テストを作ろう！
• その後もテストを作ろう！
• 他のスペックの作業にも手伝いましょう！

→ Move the Web Forward http://www.movethewebforward.org/

Save the Web,
Write Some Tests!

良いウェブ未来を
一緒に作ろう！

スペックのリンク

• W3Cの仕様書等の文書の日本語訳集
• CSSWGの下書きスペック（英語）
• CSS3の日本語訳集（もんどさん）
• WHATWGの下書きスペック（英語）
• Inside CSSWG, by fantasai（英語）

テストのリンク

• CSSWGのテストスイート：GitHubとMecurial
• CSSWGのテストウィキ（英語）
• W3Cの「Web Platform」テストスイート（GitHub）
• W3CのHTMLWGのテストウィキ（英語）
• W3CのWebAppsテストウィキ（英語）