如何参与HTML标准制定流程？

HTML标准制定并非闭门造车，而是依赖公开讨论、可验证测试与跨仓库协作的严谨过程——你无法直接向WHATWG的html仓库提交PR，但可以通过在issue中提出精准问题、贡献被三大浏览器引擎每日运行的Web Platform Tests（WPT）用例，以及关注url、html-build等关联规范仓库，真正推动标准演进；这是一条不靠权限靠实证、不拼代码量拼耐心与协作的参与路径。

HTML 标准制定不接受个人直接提交 PR 到 WHATWG 或 W3C 的“最终规范”仓库；你真正能参与的地方是 html 仓库（WHATWG 主规范）的 issue 讨论、测试用例贡献，以及通过 Web Platform Tests（WPT）提交可验证的行为变更。

为什么不能直接给 html 仓库提 PR？

WHATWG 的 html 仓库（https://github.com/whatwg/html）只接受维护者合入的变更。所有实质性修改（如新增属性、修改解析规则、调整 API 行为）必须先经过公开讨论、达成共识，并由编辑手动合并——这是流程硬约束，不是权限问题。

常见错误现象：403 Forbidden 错误或 PR 被自动关闭并附带 bot 评论 “Only editors may push to this repository”。这不是账号没授权，而是设计如此。

• 编辑团队由浏览器厂商工程师（Chrome、Firefox、Safari 工程师）和长期贡献者组成，他们负责权衡实现成本、互操作性与向后兼容
• 任何 PR 若绕过 issue 讨论直接提交，几乎必然被拒
• 规范文本本身高度结构化（大量 、 等标记），手写易出错，编辑通常用专用工具生成

真正有效的起点：在 whatwg/html 开 issue

这是绝大多数人参与的第一步，也是最关键的一步。issue 不是“建议”，而是提出可验证的问题或需求，并推动形成最小可行共识。

使用场景：发现规范未定义某行为（如 <input type="date"> 在 focus 时触发 input 事件？）、现有描述歧义、与主流引擎行为不一致、缺少无障碍要求等。

• 标题要具体，避免“HTML 应该更好”之类模糊表述；推荐格式：[input] clarify whether input event fires on focus for type=date
• 正文中必须包含：当前规范原文引用（带链接）、至少两个浏览器的实际行为（附 DevTools 截图或 minimal test case）、指向相关已有讨论（如 WPT 测试、Chromium bug、Mozilla dev.platform 邮件）
• 不要在 issue 里写“我建议改成 XXX”；先问“这里是否应有明确定义？”，再等编辑或 implementer 回应

贡献 Web Platform Tests（WPT）才是最被看重的实操路径

WPT 是 HTML 标准落地的“事实裁判”。浏览器厂商每天运行数百万条 WPT 用例；一个新用例被合入，就等于把某种行为锚定为“预期标准行为”。

性能 / 兼容性影响：WPT 用例直接影响 Chrome/Firefox/Safari 的 release checklist。你提交的测试若被合入，后续任一引擎改动都必须通过它，否则视为 regress。

• 路径：fork https://github.com/web-platform-tests/wpt → 在 html/ 或对应子目录（如 html/semantics/forms/）下新增 .html 或 .any.js 文件
• 必须包含清晰的注释说明测试目的，且仅覆盖单一可验证行为（例如：测试 form.reportValidity() 是否在 novalidate 表单中仍触发 invalid 事件）
• 提交前本地运行：./wpt serve + ./wpt run chrome html/your-test.html，确认结果符合预期
• PR 描述里需注明对应 WHATWG issue 编号（如 Fixes whatwg/html#9876）

别忽略 html-build 和 whatwg/url 这些关联仓库

HTML 规范依赖多个子规范协同更新。比如 URL 解析逻辑实际由 whatwg/url 定义；html-build 控制规范生成流程（如如何渲染 、插入索引）。改错地方会导致整个 spec 构建失败或语义漂移。

容易踩的坑：html 仓库里看到某段关于 URL 处理的描述，直接去改它——其实那只是引用，真实逻辑在 whatwg/url。盲目修改会浪费时间，还可能引发 CI 报错。

• 遇到跨仓库概念（如 origin、fetch、structured clone），先查 spec references 小节，确认归属
• html-build 的变更通常只需编辑团队操作，但如果你发现生成后的规范链接失效、索引缺失，可以提 issue 并附构建日志片段

最常被忽略的复杂点：规范演进不是线性的。今天某个 PR 被拒，可能因为三个月后 Blink 正在实验一项新行为，编辑要等数据反馈；而你提交的 WPT 测试，哪怕只跑通一个引擎，也可能成为后续对齐的起点。耐心比代码量重要得多。

今天关于《如何参与HTML标准制定流程？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！