html中无官方“实验性api”标注机制，注释仅作可读性标记且被浏览器忽略；必须通过javascript运行时检测（如"dialog" in window）并配合显式降级策略实现兼容。
html 本身没有“实验性 api”的官方标注机制，所谓“实验性 api 注释”其实是开发者在代码中自行添加的可读性标记，不是浏览器解析或标准认可的语法。
HTML 中无法用注释声明实验性特性
HTML 注释 <!-- ... --> 完全被浏览器忽略，既不触发任何行为，也不参与特性检测。你写 <!-- @experimental: <dialog> --> 或 <!-- feature:dialog (origin trial) -->，对运行时毫无影响——它只是给人看的。
常见错误现象：
- 误以为加了注释就能让
<dialog></dialog>在旧版 Safari 自动降级或打补丁 - 把注释当配置项，指望构建工具（如 Vite、Webpack）自动识别并注入 polyfill
- 在团队协作中依赖注释代替真实检测逻辑，导致上线后白屏或交互失效
真正有效的实验性特性处理方式
必须结合 JavaScript 运行时检测 + 显式降级策略。HTML 只负责承载最终确定可用的结构。
- 用
"dialog" in window或typeof HTMLDialogElement !== "undefined"判断<dialog></dialog>是否可用 - 检测失败时，动态插入替代方案（如
<div role="dialog"> + 手动管理焦点和 backdrop）<li>若依赖 Origin Trial，需在 <code>中添加<meta http-equiv="origin-trial" content="...">，且该 token 必须由 Chrome 团队签发并启用 - 服务端渲染（SSR）场景下，不能只靠客户端 JS 检测——需配合 User-Agent 特征或明确的客户端能力上报做预判
注释可以怎么写才实用
如果坚持加注释，目标应是提升团队可维护性，而非欺骗浏览器。建议格式统一、带上下文：
<!-- EXPERIMENTAL: <dialog> ✅ Supported: Chrome 97+, Edge 97+, Firefox 111+ (behind flag) ❌ Not supported: Safari (as of 17.5), all IE ? Requires JS fallback + aria-modal management --> <dialog id="confirm-dialog">...</dialog>
关键点：
- 避免模糊词如“新 API”“可能不兼容”，写具体浏览器版本和状态（stable / behind-flag / origin-trial）
- 注明是否需要配套 JS 行为（例如
<dialog></dialog>的.showModal()调用不可省略） - 不混用 Markdown 或 emoji（部分 IDE/CI 工具解析异常），纯 ASCII 更稳妥
为什么不用 data- 属性代替注释
有人尝试用 <dialog data-experimental="true"></dialog>，但这是误导性的设计：
-
data-属性不会改变元素语义或行为，<dialog data-experimental></dialog>在不支持的浏览器里依然会渲染为无样式的<dialog></dialog>，甚至引发布局崩溃 - 它容易让人误以为“加了属性就等于启用了特性”，掩盖了真实检测缺失的问题
- 自动化工具（如 Lighthouse、axe）不会识别这类自定义标记，无法用于合规性检查
真正要做的，是在 JS 初始化阶段根据能力检测结果决定是否挂载 <dialog></dialog>，而不是靠 HTML 标记“假装支持”。
最常被忽略的一点：实验性特性往往伴随隐式依赖，比如 <dialog></dialog> 需要 focus() 管理、keydown 拦截 Esc、click 拦截 backdrop —— 这些从来不在注释里写清楚，但恰恰是上线后出问题的核心。
