WHATWG HTML标准是持续更新的活标准，无固定版本号，浏览器实现常滞后于标准；开发者应以浏览器兼容性为准，结合运行时检测与MDN/caniuse验证，而非仅依赖标准文档或工具校验。
WHATWG 的 HTML 标准是“活标准”，没有固定版本号
HTML 不再像过去那样按年发布 HTML5、HTML5.1 这类带编号的快照标准。WHATWG 维护的 HTML Standard 是一个持续更新的文档，每次修改都直接反映在官网（https://html.spec.whatwg.org/）上。这意味着你看到的永远是最新状态，但同时也意味着——没有“稳定版”可锁定。
常见误解是以为 HTML5 是个终点；实际上，浏览器厂商和开发者现在默认对齐的就是 WHATWG 的活标准，W3C 已于 2019 年停止独立维护 HTML 标准。
浏览器实现往往滞后于 WHATWG 更新
WHATWG 提案通过后，需经浏览器引擎（Blink、Gecko、WebKit）实现、测试、上线，这个过程可能耗时数月甚至跨年。比如 <dialog> 在标准中存在多年，Chrome 直到 2023 年才默认启用，Firefox 则更晚。
判断某特性是否可用，不能只查 WHATWG 文档，必须交叉验证：
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 查
https://caniuse.com/或https://mdn.mozilla.org/的兼容性表格 - 看目标浏览器的 release notes（如 Chrome 124 新增了
Popover API支持） - 用
if ('popover' in HTMLElement.prototype)做运行时检测，而非仅靠标准存在性
开发者真正该关注的是“浏览器事实标准”而非“WHATWG 最新行”
WHATWG 更新频繁，但多数变更属于边缘修复、澄清语义或新增实验性 API（如 Document.adoptedStyleSheets），并不影响日常开发。真正需要警惕的是那些已进入主流引擎、但尚未被广泛认知的特性：
-
<input type="datetime-local">在 Safari 中长期不支持，但 WHATWG 标准里一直存在 -
Element.scrollIntoView({ scrollBehavior: 'smooth' })的行为差异：Firefox 曾忽略block参数，直到 v115 才修正 -
fetch()的keepalive选项虽在标准中，但实际受浏览器限制（仅限POST、大小限 64KB）
与其紧盯 WHATWG commit log，不如订阅 Chromium 的 blink-dev 邮件列表或关注 MDN 的 “Browser compatibility” 更新标记。
构建工具和 linter 很难跟上活标准节奏
ESLint 插件（如 eslint-plugin-html）、HTML 验证器（如 vnu.jar）、甚至 VS Code 的内置提示，仍多基于旧版 W3C DTD 或静态 schema。它们会把合法的 WHATWG 新语法标为错误：
- 报错
Attribute 'popover' is not allowed on element button，尽管它已是标准属性 - 警告
Element 'main' cannot be child of element 'div'，但 WHATWG 明确允许嵌套（只要语义合理） - 校验器拒绝
<slot>出现在 Shadow DOM 外，却未识别exportparts这类新属性
遇到这类误报，优先以浏览器实际行为为准；若需 CI 通过，可临时禁用对应规则（如 ESLint 的 no-unknown-property），但别删掉真实存在的 bug。
活标准的好处是问题能快速修正，坏处是“标准”本身成了移动靶。最稳妥的做法：写代码时盯住浏览器支持，查文档时认准 WHATWG，调试时信 runtime 检测，而不是任何单一方的“权威声明”。
