HTML5 元素在现代浏览器中可原生实现模态弹窗，支持 showModal()、backdrop、Esc 关闭及无障碍访问；旧浏览器需用 hidden 或 aria-hidden 降级并确保焦点管理与语义正确。
HTML5 中用 dialog 实现原生弹窗最简单
现代浏览器（Chrome 97+、Edge 97+、Firefox 98+）已原生支持 元素，无需 JS 框架或 CSS 魔改就能实现可聚焦、可模态、带 backdrop 的弹窗。它比手写 position: fixed + z-index 更可靠，也比依赖 jQuery UI 或 Bootstrap 更轻量。
关键点：
-
默认不渲染在页面流中，需显式调用show()或showModal() -
showModal()会自动禁用背景交互、添加半透明 backdrop，且支持Esc关闭和点击 backdrop 关闭（可禁用） - 必须手动绑定关闭逻辑，比如监听
click或keydown，或用自动关闭
旧浏览器兼容时 fallback 到 display: none + aria-modal
IE 和 Sa
常见错误是只加 display: none 却忽略屏幕阅读器仍能读取内容。正确做法：
- 用
hidden属性或aria-hidden="true"控制语义隐藏 - 弹窗打开时，给
加inert属性（或用 JS 禁用焦点迁移），或至少设aria-modal="true"告知辅助技术 - 确保弹窗内首个可聚焦元素自动获得焦点（
focus()），关闭后焦点回到触发按钮
示例判断逻辑：
if ('showModal' in HTMLDialogElement.prototype) {
dialog.showModal();
} else {
dialog.hidden = false;
dialog.setAttribute('aria-modal', 'true');
dialog.querySelector('input, button')?.focus();
}
可视化编辑器里拖拽弹窗组件要注意 DOM 位置
很多低代码平台把弹窗当作独立组件拖进画布，但若把它放在 或 内部，showModal() 仍能工作，但 backdrop 渲染层级可能被父容器的 overflow: hidden 或 transform 截断。
安全做法是始终将 直接挂载在 底层：
- 编辑器生成弹窗时，用
document.body.appendChild(dialog)显式移动节点 - 避免嵌套在
transform、filter或will-change元素内部（它们会创建新层叠上下文，干扰 backdrop 定位） - 如果弹窗含 iframe 或第三方富文本编辑器，需额外处理
focusin事件穿透问题
为什么不用 confirm() 或 prompt()
这两个是阻塞式原生 API，会冻结整个页面 JS 执行，无法自定义样式、内容结构或交互逻辑，在可视化编辑场景中完全不可控。
更严重的是：它们在多数现代浏览器中已被限制在用户手势（如 click）触发后 300ms 内调用，否则静默失败——这对拖拽配置后自动弹出提示的编辑器流程是硬伤。
所以哪怕只是简单确认，也应统一走 或轻量封装的 Promise 弹窗函数，例如：
function showConfirm(msg) {
return new Promise(resolve => {
const dialog = document.createElement('dialog');
dialog.innerHTML = `
${msg}
`;
dialog.addEventListener('click', e => {
if (e.target.hasAttribute('data-result')) {
resolve(e.target.dataset.result);
dialog.close();
}
});
document.body.appendChild(dialog);
dialog.showModal();
});
}
真正难的不是“怎么弹出来”，而是“怎么让弹窗在编辑器各种嵌套预览模式、iframe 沙箱、CSS scope 下依然准确定位、焦点可控、无障碍可用”。这些细节往往在导出 HTML 后才暴露。
