原生<dialog>标签不能直接用showModal()实现提示框，因其强制模态行为（遮罩、焦点锁定、Esc关闭）违背提示框“不打断操作”定位；应改用open属性+CSS动画+定时器自动关闭，并确保role="status"、aria-live="polite"、直属于body等可访问性与兼容性要求。
原生 <dialog> 标签本身不提供“消息提示框”语义或行为，所谓“封装提示框”，本质是用它实现一个无交互、自动关闭、不可取消的轻量浮层——但必须绕过它的模态默认逻辑，否则会锁焦点、加遮罩、响应 Esc，完全违背提示框需求。
为什么不能直接用 showModal() 做提示框
showModal() 会强制添加 backdrop、捕获焦点、禁用背景 tab 导航，并且用户按 Esc 或点遮罩都能关闭——这和“一闪而过、不打断操作”的提示框定位冲突。用它做提示框，反而要费力禁用这些特性，得不偿失。
- 调用
showModal()后必须手动dialog.close()，但此时 backdrop 仍存在、焦点仍被锁，直到 close 完成 - 无法可靠阻止 Esc 关闭：即使
event.preventDefault()在keydown中拦截，Safari 仍可能穿透 -
show()虽无 backdrop 和焦点锁，但不居中、不自动聚焦、也不保证渲染层级，连基本显示都不可靠
真正可行的提示框封装路径：用 open 属性 + CSS 动画 + 自动关闭
提示框的核心诉求是「可见 → 显示内容 → 自动消失」，不需要模态控制。应放弃 showModal()，改用 open 属性控制显隐，配合 CSS 过渡和 JS 定时器完成闭环。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- HTML 结构保持简洁：
<dialog id="toast" role="status" aria-live="polite"><p></p></dialog>；role="status"和aria-live="polite"确保屏幕阅读器可读 - JS 触发只设
dialog.open = true，不调用任何方法；关闭时设dialog.open = false，并监听toggle事件清理定时器 - CSS 必须重写定位：
dialog { position: fixed; top: 24px; right: 24px; width: max-content; max-width: 80%; }，禁用浏览器默认居中逻辑 - 动画靠
@keyframes+transition实现淡入/滑入，避免依赖show()的渲染时机
容易被忽略的兼容性雷区
Safari 对 <dialog> 的支持仍不稳定，尤其在非模态场景下：16.3 及更早版本中，dialog.open = true 可能不触发重绘；父容器含 transform 或 will-change 时，dialog 内容直接不渲染。
立即学习“前端免费学习笔记（深入）”；
- 不要把提示框
<dialog>放在<main>、<article>或任意带 CSS 变换的容器内；必须直属于<body> - 避免在
dialog内使用position: fixed子元素（Safari 渲染异常） - 不要依赖
getBoundingClientRect()判断是否显示——未激活的 dialog 返回空值，这是规范行为，不是 bug - 若需降级，polyfill（如
dialog-polyfill）仅补showModal()，对open属性驱动的提示框无效，得另写 fallback
提示框真正的难点不在“怎么弹出来”，而在“怎么确保它不抢焦点、不卡住键盘导航、不破坏屏幕阅读器流、且在 Safari 里真能出现”。所有封装逻辑，都要围绕这四点校验，而不是堆砌 show/close 调用。
