要約

  • W3Cは2026年8月10日にWeb Performance Working Groupの新憲章を承認し、期限を2028年8月1日とした。
  • 新機能をCandidate Recommendationとして維持される仕様に取り込む前に、少なくとも二つの実装者から関心表明を得ることが望ましいと定めた。
  • 二つの関心表明がなくてもCR Draftに入れることはできるが、その機能にはat-riskの注記が必要になる。
  • Candidate Recommendationを越えるには、機能ごとに独立した二つの相互運用実装とオープンテストが期待される。一方、W3C Processには理由を公開する例外もある。
  • 機能別の証拠状態票で、関心、WG採用、at-risk、実装の独立性、テストの版、移行決定を別々に追うべきである。

「支持」を弱めたのではなく、正確にした

Web Performance Working Groupは、読み込み、描画、操作への応答、メモリー、障害など、Webアプリケーションの体感に直結するAPIを扱う。W3Cは8月10日に再憲章と参加募集を発表し、活動期間を2028年8月1日までとした。

6月の提案と最終版を比べると、成功基準の一文が変わっている。提案は二つ以上の実装者によるsupportを求めていた。承認版は、二つ以上の実装者によるexpressions of interestと書く。関心表明が示す範囲を、実装コミットより狭く保ったのである。

実装者は、問題設定に価値を認め、レビューや試作に参加しながら、製品化をまだ決めていないことがある。リリース時期、既定での有効化、長期保守を約束せずに技術的な選択肢を残すことも合理的だ。その発言は初期判断の材料になるが、出荷済み機能として数えてはならない。

後段の基準は別の問いに答える。Candidate Recommendationを越える際には、仕様の各機能について少なくとも二つの独立した相互運用実装が期待され、オープンなテストスイートで確認できることが求められる。すべての機能にオープンテストも必要だ。ここでは組織の姿勢ではなく、異なる実装が観測可能な振る舞いを共有するかを測る。

関心と相互運用性は、賛成度の大小ではない。証拠の種類が違う。

一つの機能に四つの状態がある

最初はインキュベーションである。Web Platform Incubator Community Groupでは、ユースケースや初期コードを育てられる。その時点でWebPerf WGが正式に採用したことにはならない。

次にWG採用がある。憲章は、WICGの提案が少なくとも一つの主要ブラウザーに実装され利用可能で、さらに別の支持を得た場合、WebPerf WGが採用し得るとする。採用は標準化作業の担当と意思決定の場を変えるが、独立した二番目の実装を作り出すわけではない。

三番目はCandidate Recommendation Draftへの収載である。関心表明が二つなくても、at-riskと明記すれば機能を含められる。検討や実装経験を集めつつ、後の移行で残るとは限らないことを公示する状態だ。

四番目が実装経験による移行である。W3C ProcessはCandidate Recommendationを実装経験を集める段階と位置づける。また、変更案をレビューに示すCR Draftと、移行や特許上の役割が異なるCR Snapshotを区別する。「CRにある」という説明だけでは、文書と機能の状態を特定できない。

単一の「support」欄では、一般的な賛意、試験実装、フラグ付き機能、WGの採用決定、部分的なテスト成功、二つの独立実装を区別できない。チェックマークが同じでも、次の判断に使える重みは異なる。

Mozillaの回答は広げずに読む

Mozillaは公開したレビュー回答で、修正が採用されるかどうかにかかわらず提案を支持し、二実装者のsupportに関する文言変更も支持した。さらに、ドラフトのレビュー、実験的実装と経験報告、成果を使った製品開発への意向を示した。

公開回答の実装スケジュール欄に具体的な日付はない。

これは曖昧さではなく、発言の境界である。グループ活動への広い関心は示すが、特定機能について二社分の表明を揃えたものではない。ブラウザーの版や既定有効化日も約束していない。別の資料がこの回答を「実装済み」と言い換えれば、Mozillaが書かなかった内容を追加することになる。

参加者一覧にも同じ注意が要る。参加は議論と貢献の経路を開く。全仕様への支持や製品ロードマップの代理にはならない。

At-riskは失敗判定ではない

日常語の「リスクあり」は失敗予測のように聞こえる。しかしProcess上の注記は、ある機能が後の移行で定められた手順により削除され得ると知らせる役割を持つ。実験の余地を残しながら、文書全体の成熟度を機能に自動継承させない仕組みである。

注記は機能の識別子と仕様の版に結び付けなければならない。後に消えた場合、二つ目の関心が得られたのか、実装が整ったのか、機能自体を削ったのか、編集上の移動なのかを履歴で示す必要がある。

テスト結果も版なしでは意味が弱い。「二つのブラウザーが合格」という表現には、製品とエンジンの版、既定で有効か、WPTのリビジョン、機能カバレッジ、未解決の失敗が欠けていることがある。二つの製品名が同じコード系列を使う場合もあるため、独立性には説明が要る。

例外を隠さない

憲章は二つの独立実装を「期待」する。W3C Processは、やむを得ない理由がある場合、Teamが最小限の実装経験で移行を承認できるとし、その決定と理由の公開を求める。

例外は基準を無効にするのではなく、別の決定記録を生む。誰が、どのProcess版で、どの範囲に、どの証拠を見て例外を適用したかが分かればよい。独立性の弱い二実装を形式的に数えるより、透明な例外の方が説明責任を果たす場合もある。

Heng Luが示す「公開と採用は同じではない」という考えは、制度ラベルだけで運用現実を上書きしないために有効だ。ただし、逆方向の越境も避けるべきである。動くコードだけでW3C Recommendationを名乗ることはできない。運用証拠と制度上の状態を同じ記録で示し、互いに代用しないことが必要になる。

機能別の証拠状態票

憲章、仕様、issue、テスト、決定、公開状態はすでに存在する。次の項目を結ぶ小さな票があればよい。

  • 機能の固定識別子と仕様の不変リビジョン
  • 適用される憲章とW3C Processの版
  • 公開された関心表明ごとの実装者、日付、範囲、出典
  • 探索、予定、実装済み、撤回、または時期未定という表明の性質
  • WG採用決定と採用対象の提案版
  • at-risk注記のURI、付与日、変更履歴
  • 実装の製品、エンジン、版と独立性の根拠
  • オープンテストのリビジョン、カバレッジ、日付付き結果
  • 移行決定、異議、公開されたProcess例外
  • 次回レビュー、訂正、置換状態

企業秘密や未公開ロードマップを求める必要はない。「関心はあるが時期は未定」という表明を、そのままの強さで保存することが目的である。

新憲章は、注意を向ける根拠と相互運用を証明する根拠を分けた。調達仕様や互換性表も、その区別を失わない設計にできる。

出典

  1. W3C — 憲章承認と参加募集の通知
  2. W3C — 承認済みWeb Performance Working Group憲章
  3. W3C — 提案版と承認版の差分
  4. W3C — 憲章案の公開レビュー告知
  5. W3C公開レビューアーカイブ — Mozillaの回答
  6. W3C — Process Document
  7. W3C — Web Performance Working Groupの公開文書
  8. W3C — Web Performance Working Group
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption