验证HTML全局属性需运行时闭环测试：contenteditable用isContentEditable判断、hidden需CSS兜底、inert须实测交互拦截、draggable/spellcheck等要读写验证效果，不可依赖in操作符或UA字符串。
HTML全局属性（如 contenteditable、hidden、inert、draggable、spellcheck）在不同浏览器中表现不一——不是“有或没有”，而是“有但行为异常”或“存在却不可靠”。直接查 MDN 或 caniuse 只能告诉你“是否标称支持”，无法反映真实运行时表现。
怎么验证 contenteditable 是否真能编辑
很多页面在 Safari 或旧版 Edge 中显示可编辑框，点击却无光标、无法输入，根源是 contenteditable 被解析但底层编辑引擎未激活。
- 手动测试：在目标浏览器中右键检查元素，确认
contenteditable="true"属性存在且未被 JS 动态移除 - 运行时验证：执行
document.querySelector('[contenteditable]').isContentEditable，返回true才算真正可用；IE11 返回undefined也属正常，但需降级为textarea - 注意 iOS Safari 的特殊限制：
contenteditable元素若未设置tabindex="0"，软键盘可能不弹出 - 避免嵌套：Chrome 120+ 对
div[contenteditable] > p[contenteditable]的光标定位有 bug，建议扁平化结构
为什么 hidden 在 IE 和部分 WebView 中失效
hidden 是布尔属性，语义上等价于 display: none，但它不触发重排，且可被 JS 动态切换。问题在于：IE10–11 和 Android 4.4 WebView 完全忽略该属性，既不隐藏也不影响 DOM 可访问性。
- 检查方式：用
getComputedStyle(el).display判断是否为none，不能只看属性是否存在 - 安全写法：CSS 中强制兜底
[hidden] { display: none !important; }，并确保该样式表在所有浏览器中加载 - 慎用于 ARIA 场景：SR（屏幕阅读器）对
hidden的支持比视觉渲染更滞后，iOS VoiceOver 16.4 对动态添加hidden有 300ms 延迟
如何实测 inert 的交互拦截是否生效
inert 是最易误判的全局属性——Safari 16.2–16.3 声称支持（typeof HTMLDivElement.prototype.inert !== 'undefined'），但设为 true 后仍可 focus、click、键盘操作。仅靠构造函数检测会踩坑。
立即学习“前端免费学习笔记（深入）”；
- 必须运行时验证：创建临时元素，赋值后立即测试交互响应
- 示例脚本：
const el = document.createElement('div');<br>el.inert = true;<br>el.innerHTML = '<button>test</button>';<br>document.body.appendChild(el);<br>const btn = el.querySelector('button');<br>btn.focus(); // 检查是否真的失焦<br>btn.click(); // 检查 click 事件是否被拦截<br>document.body.removeChild(el); - 当前可靠 fallback：用
aria-hidden="true"+tabindex="-1"+ CSSpointer-events: none组合模拟
哪些全局属性根本不能靠 in 操作符检测
像 draggable、spellcheck 这类属性，即使浏览器完全不支持，'draggable' in element 也可能返回 true（因为 DOM 接口继承自 HTMLElement，属性名存在但无实际行为）。
- 正确检测方式：读写后验证效果。例如：
el.draggable = true; console.log(el.draggable)—— 若返回false，说明不支持 -
spellcheck在 Firefox 中对contenteditable元素有效，但在 Chrome 中仅对input/textarea生效，需按上下文分别验证 - 不要依赖 UA 字符串：
navigator.userAgent.includes('Safari')无法区分 macOS Safari 17 和 iOS Safari 17.5，二者对spellcheck的 spellcheck 引擎调用策略不同
真正决定兼容性的，从来不是“文档写了没”，而是“浏览器执行后有没有副作用”。每个全局属性都得单独跑一次“读-写-触发-观察”的闭环验证，跳过这步，上线后遇到的就不是样式错位，而是功能静默失效。
