摘要

  • W3C 于 2026 年 8 月 10 日批准 Web Performance 工作组新章程，授权期到 2028 年 8 月 1 日。
  • 最终文本要求，新特性在纳入以 Candidate Recommendation 状态维护的规范前，应至少取得两家实现方的兴趣表达。
  • 若没有两份兴趣表达，特性仍可进入 Candidate Recommendation 草案，但必须明确标成 at risk。
  • 要越过 Candidate Recommendation，章程期待每个特性都有两个独立且可互操作的实现，并以开放测试验证；W3C Process 同时保留公开说明理由的例外路径。
  • 因此应为每个特性建立一张证据状态单，把兴趣、工作组采纳、风险标注、实现身份、测试版本和阶段决定分别保存。

一处措辞改动，划开两种事实

Web Performance 工作组处理的是用户每天都能感觉到、却不一定看得到的系统行为：页面加载、渲染、交互延迟、响应能力、内存与应用故障。W3C 在 8 月 10 日发布批准通知，并把这届章程的结束日期定为 2028 年 8 月 1 日。

从 6 月提案到批准文本，Success Criteria 中的一句话变了。提案谈的是至少两家实现方的 support；最终章程改成至少两家 implementor 的 expressions of interest。它没有把“兴趣”写成“实现承诺”，这是更准确的边界。

一家浏览器厂商可以认为问题值得解决，愿意审阅草案、试做原型，或者希望某个技术选项暂时不要关闭。它未必已经分配产品团队，也未必承诺默认开启、出货日期或长期兼容。兴趣声明仍然是有用证据，但它回答的是“是否值得继续投入”，而不是“是否已经互通”。

章程把后一个问题放在更晚的门槛。规范若要越过 Candidate Recommendation，预期每个特性至少有两个独立、可互操作的实现，并由开放测试套件核验；每个特性还必须有开放测试。此时考察的不是态度，而是不同系统面对同一组可复查测试时是否呈现兼容行为。

两种记录都重要。把它们塞进同一个“支持”格子，才会让信息失真。

一个特性至少有四个状态

首先是孵化。提案可以在 Web Platform Incubator Community Group 形成用例、讨论和早期代码；这并不表示 Web Performance 工作组已经把它纳入自己的规范任务。

其次是工作组采纳。章程的协调条款说，一个 WICG 提案如果已在至少一个主要浏览器中实现并可用，又得到另一方支持，就可能被 WebPerf 采纳。采纳改变了正式工作的机构归属，却没有自动产生第二个独立实现，也没有让每项测试通过。

第三是进入 Candidate Recommendation Draft。即使不足两份兴趣表达，特性也可被放入草案，但必须带着 at-risk 标注。这种安排允许实现经验继续累积，同时明示该特性可能在后续阶段被移除。文档的总体阶段不能替特性取消这个条件。

第四才是用实现与测试支撑阶段跃迁。W3C Process 把 Candidate Recommendation 定义为收集实现经验的阶段，并区分用于呈现拟议变更的 CR Draft 与具有不同过渡和专利审查作用的 CR Snapshot。“已经在 CR”如果没有文档类型、版本和特性状态，仍是一句不完整的话。

一张绿色勾选表可能把下列情况混为一谈：有人公开赞成继续研究；实验代码在 flag 后运行；工作组投票采纳；部分 WPT 通过；两个品牌使用相同底层代码；或两个真正独立的实现已通过同一版本的测试。颜色相同，证据完全不同。

Mozilla 的公开回复恰好说明了边界

Mozilla 在公开的章程审查回复中表示，无论其建议是否被采纳，都支持这份提案；它也支持修改“至少两家实现方支持”的措辞。对交付物，Mozilla 勾选了审阅草案、开发实验实现并提交经验报告、以及基于工作成果开发产品等意向。

公开回复中的实现时间表没有填写具体日期。

这不构成缺陷。它说明声明的范围就是一般参与意向，而非逐特性路线图。回复没有为某个 API 列出两家实现方，没有指定浏览器版本，也没有承诺何时默认开放。如果公共材料把这份回复直接计作某个特性的“第二个实现”，就增加了原声明中不存在的含义。

成员名单也不能代替这一证据。组织参加工作组，意味着它拥有参与讨论与贡献的渠道；不意味着它对每一个 deliverable 都投了赞成票，更不意味着每一个产品线都会实现。

At risk 不是失败预测

在普通语境中，“有风险”像是对结局的悲观判断。在 W3C 流程里，它有更精确的程序作用：提醒审阅者，这个特性可在后续跃迁中按规定路径移除，不应因为它所在文档的阶段而被误认成确定保留。

风险标注必须绑定到明确的特性和文本修订。如果标注后来消失，历史记录应回答原因：第二份兴趣是否到来，独立实现是否完成，特性是否被缩小或删除，还是编辑仅仅调整了章节位置。只保留最新页面无法区分这些情况。

开放测试也必须带版本。所谓“两个浏览器通过”，需要说明浏览器和引擎版本、是否默认启用、WPT 修订、覆盖范围与未通过项目。两个产品名称不一定代表两套独立实现；独立性需要根据代码来源和实现决定给出理由，而不是从商标数量推断。

例外也要成为可见状态

章程对两个独立实现使用的是“预期”措辞。总的 W3C Process 允许 Team 在有充分理由时，以最少实现经验批准跃迁，但必须公开这一决定及其理由。

这条例外不是把普通标准作废，而是产生另一份需要归档的决定：谁依据哪一版 Process，针对哪个范围，以什么证据作出判断，为什么例外比继续等待更合适。公开解释的例外，有时比用共享代码拼出两个名义实现更诚实。

Heng Lu 对“发布”与“采纳”的区分可用来校正一半问题：声明本身不能代替实现、验证和实际使用。但另一半同样重要——运行中的代码不会自行取得 W3C Recommendation 身份。技术事实和机构阶段各有决定者。治理记录必须把两者连接起来，而不是让一方冒充另一方。

为每个特性留一张证据状态单

W3C 已经公开章程、规范、issue、测试仓库、会议决定和发布状态。缺少的是一张轻量连接表。它可以包含：

  • 稳定的特性标识与不可变规范修订；
  • 适用的章程及 Process 版本；
  • 每份公开兴趣表达的实现方、日期、范围和来源；
  • 声明究竟是探索、已排期、已实现、撤回，还是没有时间承诺；
  • 工作组采纳决定及被采纳的提案版本；
  • at-risk 标注的 URI、加入时间和变更历史；
  • 每个实现的产品、引擎与版本，以及为何算作独立实现；
  • 开放测试修订、特性覆盖率和带日期的结果；
  • 阶段跃迁、异议和公开的 Process 例外；
  • 下次复核、纠错与替代状态。

这张表不需要公开商业机密或内部路线图。实现方完全可以只声明“有兴趣，尚无时间表”。记录的价值正在于不让这句有边界的话，在传播中升级成出货承诺。

新章程已经把问题说清：兴趣是进入视野的理由，开放测试与独立实现才是互操作证据。接下来要做的是让采购条款、新闻标题和兼容性列表也保留这个差别。

来源

  1. W3C——章程批准与参与通知
  2. W3C——获批的 Web Performance 工作组章程
  3. W3C——提案与获批文本对比
  4. W3C——章程提案公开审查通知
  5. W3C 公开审查档案——Mozilla 回复
  6. W3C——Process Document
  7. W3C——Web Performance 工作组发布页面
  8. W3C——Web Performance 工作组页面
  9. Heng Lu——Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption