摘要

  • W3C 的 Browser Testing and Tools 拟议章程准备让 WebDriver 与 WebDriver BiDi 发布 Candidate Recommendation Snapshot，并在该阶段持续更新，不以进入 Recommendation 为既定目标。
  • 这仍是章程提案，不是已经生效的决定；两份现行技术报告也仍是 Working Draft。2018 年的 WebDriver Recommendation 是同一系列中的另一个已发布状态，不能自动覆盖新稿。
  • Candidate Recommendation Snapshot 与 Draft 的审查、专利和变更含义不同，二者都不能被称为 W3C 标准。
  • 可复现实验至少要连接不可变规范快照、成熟度类别、测试仓库提交与选集、浏览器/驱动/客户端构建、平台、日期和已知排除项。

“持续候选推荐”不是延期，而是一种制度设计

WebDriver 把点击、导航、查找元素等动作变成跨浏览器协议。WebDriver BiDi 又让事件从浏览器反向流向控制程序。它们的实际形态分布在许多地方：W3C 技术报告、Web Platform Tests、浏览器引擎、驱动程序、自动化库，以及依赖这些组件做发布判断的持续集成系统。

W3C 于 2026 年 8 月 18 日开启新章程审议，公众意见截止 9 月 18 日，现行章程则延长到 10 月 23 日。本文截点时，后继章程尚未获批。不过，提案对未来维护方式的表述很清楚。

章程保留 WebDriver 与 WebDriver BiDi 两项规范性交付物。工作组计划把最新工作发布为 Candidate Recommendation，并通过 Snapshot 留下阶段节点；达到这一状态后仍持续更新，而且明确“不打算”把文件推进到 Recommendation。

这句话把通常被看作中间站的成熟度，改造成计划中的长期终点。W3C 自己的 living CR 指南承认这种选择：当规范必须从多个代码库不断吸收实现经验时，Candidate Recommendation 可能比间隔很长的最终版本更贴近真实开发。

但长期终点也改变了引用的责任。若没有最终 Recommendation 作为显而易见的稳定锚点，合同、测试报告与产品说明仍会写“WebDriver”。这个系列名却不能回答：引用的是哪一版算法，跑的是哪批测试，浏览器里是哪一份代码。

章程表里的日期已经说明“系列”与“版本”不是一回事

拟议章程把 2026 年 4 月 1 日的 WebDriver 与 3 月 19 日的 WebDriver BiDi 列为最新发布。到 8 月 31 日，W3C 的实时技术报告页面已经分别前进到 7 月 2 日和 8 月 25 日。

这不证明章程错误，更不构成失职指控。章程需要起草与审议，活跃规范可以在此期间多次发布。差异真正证明的是授权对象：章程管理一个会继续变化的规范系列，不会冻结实现方昨天阅读过的那组字节。

名称还可能覆盖多个成熟度。W3C 目录保留 2018 年 6 月的 WebDriver Recommendation，同时又把新的 WebDriver 文本列作 Working Draft。新稿不能因为同名而借用旧稿的 Recommendation 身份；旧 Recommendation 也不会自动包含后来加入的所有命令。

latest 地址适合追踪今天的文本，却不适合独自承担历史证据。几个月后，它可能显示新算法，而被调查的旧浏览器与驱动仍执行此前逻辑。

Snapshot 与 Draft 保留的是两种不同证明

W3C Process 把 Candidate Recommendation 分成 Snapshot 与 Draft。Snapshot 必须通过经核验的迁移或更新请求，也是 Patent Review Draft。W3C 的公开说明把工作组共识、公众审阅、其他 W3C 组的正式审查，以及成员的免版税许可承诺与它相连。

Candidate Recommendation Draft 则把 Snapshot 之后准备采用的变化整合起来，方便阅读和测试。为了让规范及时更新，其发布门槛被有意降低。公开说明明确指出，这些变化尚未正式审查，Draft 本身也不提供 Snapshot 对应的排除机会。

两者都不是 W3C 标准。Snapshot 也不自动证明已有充分实现经验。living CR 指南直言，其中仍可能有变化中的功能、实现分布不均、互操作有限，甚至测试尚不完整。

这些限制并非否定 Snapshot。相反，它们让状态可解释：Snapshot 是已经过一定审查的实现目标和专利节点；Draft 是随后变化的集成视图；Recommendation 才另外带来 W3C 背书与更高的实现经验门槛。把三个名称压成一个“标准”，才会丢掉治理信息。

支持结论必须是一条可重跑的连接

新章程已经写入若干正确方向：Candidate Recommendation 中的变化和已经部署的功能应有 Web Platform Tests；新功能应至少得到两个潜在实现者的兴趣表达；安全、隐私和无障碍影响应单独记录；重大转换需要横向审查。

可惜任何单项都不等于互操作。兴趣表达不是代码；测试文件存在不等于覆盖了规范义务；绿色结果若没有测试提交和浏览器构建，就无法日后重现；实验功能可能只在开关后可用；驱动与客户端库也可能只暴露协议的一部分。

对重要决定，最小证据组合应是：

不可变规范快照 + 成熟度类别 + 测试提交与选集 + 浏览器/驱动/客户端构建 + 平台 + 运行日期 + 已知排除项

若测试 Candidate Recommendation Draft，还要注明此前的 Snapshot 与本次覆盖的实质变化；若引用 Snapshot，应连接迁移或更新决定与专利审查状态；若规则写的是 latest，则必须记录解析方法、解析时间和最终得到的不可变地址。

这并不是另建认证机构。W3C 决定发布状态，工作组决定规范文本，浏览器和工具项目决定发什么代码，使用者决定采用哪一组。证据组合只负责保存它们实际相遇的那一刻。

不必把文章误读成“必须进入 Recommendation”

现有材料不足以证明 WebDriver 必须追求 Recommendation。W3C 明确认可 living CR 的合理性。对高度依赖实现反馈的浏览器自动化协议，持续可审阅的目标可能比稀疏的最终版本更诚实。

风险来自“持续变化”丢掉版本以后。一份 Draft 上的局部通过，可以被包装成整个 WebDriver 系列的支持；后来的文本可以倒灌进旧合同的解释；同一个标签会洗掉审查程度和行为差异。

冻结证据并不冻结开发。新的 Snapshot、新测试提交与新浏览器会生成新组合。团队仍可快速推进，外部读者也能判断两次结论究竟哪里不同。

不确定性

Advisory Committee 可能接受、修改或拒绝章程，长期 CR 条款也可能变化。WebDriver 与 WebDriver BiDi 目前尚未达到提案描绘的 Candidate Recommendation 阶段，文本也没有给出首次迁移日期。

本文不评定今天的浏览器互操作性，也不把 WPT 实时面板当成裁决。不同用途所需细节不同：调试主干代码与执行五年期采购合同，本就不应使用同一种证据寿命。

可以确定的只有边界：若 Candidate Recommendation 被设计成持续终点，精确版本身份就不再是工程附注，而是治理成果的一部分。系列名说明工作属于哪里，不能说明当时跑了什么。

来源

  1. W3C 新章程审议公告
  2. Browser Testing and Tools 拟议章程
  3. Browser Testing and Tools 现行章程
  4. W3C Process
  5. W3C 对最终成熟阶段的说明
  6. W3C 发布的文档类型
  7. WebDriver 最新技术报告
  8. WebDriver 发布历史
  9. WebDriver BiDi 最新技术报告
  10. WebDriver BiDi 发布历史
  11. WebDriver BiDi 的 WPT 结果
  12. WebDriver BiDi 的 WPT 测试目录