contenteditable 是唯一能直接使任意 HTML 元素变为可编辑区域的全局属性，但需配合 tabindex="0" 实现键盘聚焦，且合法值仅 true、false 和空字符串；其误用易导致可访问性失败。
contenteditable 是唯一一个能直接让任意 HTML 元素变成可编辑区域的全局属性，但它不是“开关即用”——开错位置、漏掉 tabindex、忽略默认样式干扰，都会导致行为异常或可访问性断裂。
哪些属性真正属于 HTML 全局属性（2026 年有效）
MDN 当前（2026 年 4 月）明确列为全局属性的有：accesskey、autocapitalize、autocorrect、autofocus、class、contenteditable、dir、draggable、enterkeyhint、exportparts、hidden、id、inert、inputmode、is、itemid、itemprop、itemref、itemscope、itemtype、lang、nonce、part、popover、slot、spellcheck、style、tabindex、title、translate、virtualkeyboardpolicy。
注意：xml:lang 和 xml:base 已被弃用，仅因兼容性保留；on* 类事件处理器（如 onclick）属于事件处理属性，不是 HTML 规范定义的“全局属性”，而是 DOM 接口层面的支持。
-
inert在 Chrome 122+、Firefox 125+ 才稳定支持，旧版需 polyfill 或降级逻辑 -
popover和virtualkeyboardpolicy属于较新实验性属性，Safari 目前不支持virtualkeyboardpolicy -
is仅在自定义元素已通过customElements.define()注册后才生效，否则会被忽略
contenteditable 的三个常见误用点
它看起来简单，但实际项目里最容易出问题：
立即学习“前端免费学习笔记（深入）”；
- 设为
contenteditable="true"后，元素默认不可聚焦 —— 必须同时加tabindex="0"，否则键盘无法进入 - 设为
contenteditable="plaintext-only"并不被任何浏览器支持；合法值只有true、false、空字符串（等价于true） - 嵌套子元素若自带样式（比如
user-select: none或pointer-events: none），会阻断光标定位和文本选择
示例修正写法：
<div contenteditable="true" tabindex="0" spellcheck="false">编辑区</div>其中
spellcheck="false" 可避免拼写下划线干扰 UI。
tabindex 不只是“让它能 tab 进去”
它的数值直接影响焦点流顺序和可访问性语义：
-
tabindex="-1"：可编程聚焦（el.focus()），但不参与自然 tab 流 -
tabindex="0"：按 DOM 顺序加入 tab 流，最常用 -
tabindex="5"及正数：强制前置 tab 顺序，但会破坏屏幕阅读器的阅读流，不推荐 - 对
contenteditable元素，tabindex缺失 = 无法键盘聚焦 = WCAG 2.1 2.1.1 失败
特别注意：disabled 属性会让 tabindex 完全失效，哪怕你写了 tabindex="0" 也没用。
别把 ARIA 属性当全局属性用
role 和 aria-* 系列（如 aria-label、aria-expanded）不属于 HTML 全局属性范畴，它们是 WAI-ARIA 规范定义的语义增强属性。
关键区别：
- HTML 全局属性控制行为与基础呈现（如是否可编辑、是否隐藏）
- ARIA 属性只影响辅助技术理解，不改变 DOM 行为或默认样式
- 例如：
role="button"不会让元素响应点击，必须手动绑定click事件；而contenteditable本身就会触发输入事件
混用时容易忽略的细节：给 contenteditable 元素加 role="textbox" 是合理语义补充，但加 role="button" 就会产生语义冲突 —— 浏览器和读屏器会困惑这是个按钮还是编辑框。
