contenteditable="true"在子元素中不生效，因遵循“就近false优先”规则：任一祖先设contenteditable="false"即覆盖子级true；且必须配tabindex="0"才能获得焦点和快捷键支持。

contenteditable="true"为什么在子元素里不生效

因为 contenteditable 遵循“就近 false 优先”规则：只要任意祖先节点设置了 contenteditable="false"，哪怕子元素显式写 contenteditable="true"，也完全无效。

常见错误场景：

• 父级 <div contenteditable="false"> 包裹了可编辑区域，结果整个区域点不动 <li>组件库或框架默认给根容器加了 <code>contenteditable="false"（比如某些 CMS 编辑器外壳），子节点白配 true
• 误用 contenteditable="on" 或 contenteditable="1" —— 这些值浏览器直接忽略，退化为 inherit，最终继承到 false

验证方法：用 DevTools 检查目标元素的 computed contenteditable 值，不是看 attribute，而是看最终解析结果。

为什么点了能输字，但 Ctrl+B 没反应

因为没焦点。contenteditable 不会自动让非表单元素获得键盘焦点，document.execCommand() 和 Selection API 全部依赖有效焦点。

必须手动加 tabindex="0"：

• tabindex="0"：加入自然 Tab 键顺序，用户可键盘切换进入，推荐首选
• tabindex="-1"：只能靠 JS 调用 el.focus() 主动聚焦，无法键盘抵达
• 漏掉这步，鼠标点击能打字，但所有快捷键、选区操作、格式命令全部失效

注意：旧版 Safari 对只写 contenteditable（无等号无值）支持不稳定，务必写全 contenteditable="true" + tabindex="0"。


HTML Extract
使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...
下载

粘贴带 script 标签？回车变成

？

这是 contenteditable 的默认行为，不是 bug —— 它本就不承诺输出干净 HTML，而是把浏览器原生编辑引擎暴露给你。

关键控制点：

• 拦截 paste 事件，用 event.clipboardData.getData('text/plain') 提纯文本，再用 document.execCommand('insertText', false, text) 插入（仅作兼容过渡）
• 监听 keydown，对 Enter 调用 event.preventDefault()，然后手动插入 <br> 或自定义分隔符
• 用 MutationObserver 监听 DOM 变更，清洗掉 <script></script>、内联 style、非法嵌套等危险结构
• Chrome 121+ 支持 contenteditable="plaintext-only"，但 Firefox/Safari 仍无视，不能当主力方案

和 execCommand、designMode 是什么关系

三者同属一套已废弃的编辑 API 体系：designMode='on' 控制整个 iframe 文档，contenteditable 是其细粒度替代，execCommand 是配套命令接口。

现实问题：

• document.execCommand('bold') 在不同浏览器中可能生成 <b></b>、<strong></strong> 或带 style="font-weight: bold" 的 span
• Chrome 98+ 移除部分命令，Firefox 标记为 deprecated
• 现代方案应转向 getSelection().getRangeAt(0) + Range API 手动操作 DOM

真正容易被忽略的点：你不是在配置一个编辑器，而是在接管浏览器的编辑引擎——它默认不做任何清洗、约束或语义保证，所有责任都在你手上。