摘要

  • 2025 年现行 W3C 流程规定：一项 Recommendation 想在原文档中新增功能，须在首次成为 Recommendation 前明确选择允许新增。2026 年 10 月 25 日的流程草案拟取消这一前置条件。
  • 草案仍要求候选修订经过至少 60 天的公开征求意见、顾问委员会审查、专利排除机会和实施经验核验，才能进入规范正文。真正要固定功能范围的人，应引用带发布日期的具体版本。

标准没换地址，房间却能加一间

“符合 W3C 标准”这句话很容易写，难的是写清楚符合哪一版。负责招标的人可能把搜索结果里的链接贴进合同；工程团队可能把同一链接写进测试方案。若地址指向特定日期的版本，双方有共同的原文。若地址指向最新版，后续出版会改变链接所指的文本。技术文件里一个小小的 URL 选择，日后可能变成谁有权改变验收条件的问题。

2025 年 8 月 18 日生效的流程在新功能上画了界线。Recommendation 可以修正错误，也可以按程序修改实质内容；但要在同一份 Recommendation 里添入新功能，文档必须在首次发布为 Recommendation 前就标明“允许新增功能”。没做这个声明的工作组若要扩展技术，可以另起一份技术报告，从首次公开工作草案重新走流程。旧文档仍能维护，原有功能集合则享有默认稳定性。

2026 年 10 月 25 日草案准备拿掉这道分流。第 6.3.10.2 节允许第 3 类实质改动和第 4 类新功能，作为候选修订附在任何 Recommendation 上。草案用“为了简化”解释取消限制。对起草者而言，这少了一套术语和手续；对多年后才读到最新版链接的人而言，这意味着“同一个标准地址”不再自动等于“同一组功能”。

这份文本目前是流程社区小组的草案。W3C 自己写明，成员仍遵循现行流程；顾问委员会评议还在后面。草案尚未把任何具体规范的新功能变成正式要求。

一张没人记得领取过的保单

W3C 流程仓库的第 1168 号合并请求把代价说得很直白。提交者指出，旧规则下，未预先声明可新增功能的 Recommendation，即使持续修订文字和修错，也不会在原文档中扩张功能集合。因此，读者曾可沿着不带日期的地址追最新版本，同时相信功能范围不会变。旧区分让流程复杂、容易混淆；项目认为几乎看不到有人依赖这份保证的证据。请求在 2026 年 7 月 22 日并入草案，删除八个已定义术语；不计“退役术语”附录，净减 43 行。

“看不到依赖证据”有其合理分量，也有清晰边界。公开请求没有统计多少合同、软件或审计文件靠这项默认规则锁住功能范围。没有人到流程仓库报到，并不能替一份招标文件做版本选择。规则设计者能减少术语；使用者必须把自己接受的版本写明白。两边各有一支笔，不能互相代签。

W3C 的官方引用指南区分三类地址：“this version”指向特定发布文本，“latest published version”指向该系列最近发布的文本，编辑草案则是还在迭代的工作面。W3C 表示会尽力长期保留特定版本的原貌，仅对损坏的标记或链接作有限修复。需要稳定验收基线，就写带日期的版本；愿意跟随未来变化，就写最新版链接，并说明由谁评估变化。

新功能仍得过审，门槛变的是入口

候选修订写在注释里时，还没有改变规范正文。草案规定，要让它进入正式要求，工作组须发出拟议修订的最后征求意见，给公众至少 60 天评论，征询实施经验，接受顾问委员会审查与专利排除机会，正式处理评论，并在证明足够实施经验后申请发布更新版。另走工作草案或候选推荐标准路径，也仍然存在。

10 月 26 日 ARIA 公开会议纪要恰好展示了流程的实际摩擦：与会者讨论专利窗口、变更记录，以及跨领域审查如果来得太晚，实施者可能已按旧设计开工。会议没有替这份流程草案作采纳决定，但提醒人们：审查程序的价值，要在代码和合同凝固前兑现。

旧规则要求“未预先选择可新增”的规范另起报告，这是一个醒目的起点。草案将入口并为一条共同修订路径，保留审查，却不再由原文档的预先声明提供范围保证。W3C 可以修整自己的流程，引用者也得修整自己的版本台账。

来源