HTML标准制定不接受个人直接向WHATWG html仓库提PR，因该仓库仅限编辑手动合并变更；参与路径为：在whatwg/html开issue讨论问题、贡献Web Platform Tests（WPT）用例、关注关联仓库如whatwg/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 讨论直接提交，几乎必然被拒
- 规范文本本身高度结构化（大量
<dfn>、<span data-x="...">等标记），手写易出错，编辑通常用专用工具生成
真正有效的起点：在 whatwg/html 开 issue
这是绝大多数人参与的第一步，也是最关键的一步。issue 不是“建议”，而是提出可验证的问题或需求，并推动形成最小可行共识。
立即学习“前端免费学习笔记（深入）”；
使用场景：发现规范未定义某行为（如 <input type="date"> 在 focus 时触发 input 事件？）、现有描述歧义、与主流引擎行为不一致、缺少无障碍要求等。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 标题要具体，避免“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 控制规范生成流程（如如何渲染 <dfn>、插入索引）。改错地方会导致整个 spec 构建失败或语义漂移。
容易踩的坑：html 仓库里看到某段关于 URL 处理的描述，直接去改它——其实那只是引用，真实逻辑在 whatwg/url。盲目修改会浪费时间，还可能引发 CI 报错。
- 遇到跨仓库概念（如
origin、fetch、structured clone），先查spec references小节，确认归属 -
html-build的变更通常只需编辑团队操作，但如果你发现生成后的规范链接失效、索引缺失，可以提 issue 并附构建日志片段
最常被忽略的复杂点：规范演进不是线性的。今天某个 PR 被拒，可能因为三个月后 Blink 正在实验一项新行为，编辑要等数据反馈；而你提交的 WPT 测试，哪怕只跑通一个引擎，也可能成为后续对齐的起点。耐心比代码量重要得多。
