HTML5可视化编辑器不兼容IE8及更早版本，IE9+可通过降级策略维持基础编辑能力；需用Modernizr检测contenteditable、beforeinput等特性并渐进式降级；主流编辑器已放弃IE8–9支持，IE11需手动修复execCommand逻辑与DOM清洗。
HTML5 可视化编辑器本身不兼容 IE8 及更早版本，但可通过降级策略在 IE9+ 和部分 IE10/11 场景下维持基础编辑能力。
HTML5 contenteditable 在旧浏览器中的实际表现
IE9 开始支持 contenteditable，但行为与现代浏览器差异显著：光标定位不准、撤销栈断裂、execCommand 返回值不可靠（如 document.queryCommandState("bold") 常返回 false 即使已加粗）。IE8 完全不支持该属性，强制启用会退化为只读文本区域。
- IE9–10：可响应简单格式操作，但嵌套块级元素（如
<div><p>...</p></div>）易导致光标丢失 - IE11：支持基本 API，但
getSelection().getRangeAt(0)在 iframe 中可能抛InvalidStateError - 所有 IE 版本均不支持
beforeinput事件，无法拦截原生输入逻辑
如何用 Modernizr + 特性检测做渐进式降级
不要依赖 UA 字符串判断 IE 版本，而是检测关键能力。例如：Modernizr.contenteditable 判断是否支持编辑；'onbeforeinput' in document 判断输入事件可用性；document.execCommand 存在性验证命令执行能力。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 若
!Modernizr.contenteditable，隐藏可视化工具栏，仅渲染只读 HTML（用innerHTML渲染，禁用所有交互） - 若支持
contenteditable但不支持beforeinput，改用input+keydown组合监听内容变化，延迟 30ms 合并事件防止抖动 - 对 IE11，需手动 patch
document.execCommand的返回逻辑：比如加粗前先用getSelection()检查是否处于<strong></strong>内部，而非依赖queryCommandState
第三方库的兼容性取舍（如 Quill、TinyMCE）
主流编辑器已放弃 IE8–9 支持：Quill 2.0+ 要求 IE11+；TinyMCE 6 官方最低支持 IE11，且默认关闭对 execCommand 的依赖，改用自研 DOM 操作层——这反而提升了 IE11 下的稳定性。
- 若必须支持 IE9，可锁定
TinyMCE 4.9.11（最后一个声明支持 IE9 的版本），但需自行修补其ie_safari.js中的 selection 修复逻辑 -
CKEditor 4对 IE9 有较完整适配，但其“源码模式”在 IE9 下无法正确同步textarea值，需监听blur事件手动同步 - 任何方案都绕不开 iframe 模式：旧版 IE 中，只有将编辑器置于独立
iframe并设置document.designMode = "on"才能获得相对可控的格式行为
真正棘手的不是“能不能显示”，而是“用户以为能编辑、实际操作后状态错乱”。比如在 IE11 中连续点击两次加粗按钮，DOM 可能生成嵌套 <strong><strong>...</strong></strong>，而编辑器状态栏仍显示“未加粗”。这类问题无法靠 polyfill 彻底解决，只能靠严格限制操作路径和增加 DOM 标准化清洗步骤。
