仅强制显示元素，不触发模态行为；真正模态需调用 showmodal()，且必须确保 dom 就绪、浏览器支持并妥善降级。
dialog 的 open 属性只控制初始可见性，不是“默认弹窗”开关
写了 <dialog open></dialog> 页面一加载就看到内容，很多人误以为这就是“默认弹窗”，其实它只是绕过 JS、强制让元素从 display: none 变成 display: block，完全不激活模态行为。它没有灰色遮罩、背景可滚动、Tab 键能穿出、Esc 按下无反应、close 事件也不触发——本质上和 <div hidden> + <code>hidden=false 几乎一样。
-
open是布尔属性，仅在 HTML 解析时生效，DOM 挂载后设dialog.open = false不会关闭，也不会移除遮罩（因为本来就没有） - 浏览器不会为
open属性自动注入::backdrop，也不会接管焦点流，getBoundingClientRect()虽能取到尺寸，但焦点管理全靠你手动补 - 如果你需要用户一进页面就看到一个真正可用的模态框（比如 GDPR 同意弹窗），
open属性无法满足——必须等 DOM 就绪后调用showModal()
无脚本状态下想“默认弹窗”，open 是唯一选择，但代价明确
纯静态页面、禁用 JS、或作为降级 fallback 时，<dialog open></dialog> 确实是唯一能“不写 JS 就显示”的方式。但它只解决“看得见”，不解决“用得上”。常见后果包括：
- 用户按 Esc 没反应，可能反复按导致页面卡顿感
- 点击对话框外区域，背景内容仍可滚动、可点击，容易误操作
- 屏幕阅读器可能读不到
role="dialog"的完整语义，因为缺少aria-modal="true"和焦点锁定 - 移动端 Safari（iOS 16.3 及更早）会把
open当普通 div 渲染，既不居中也不限制缩放
为什么不能靠 CSS 强行显示 dialog？
给 <dialog></dialog> 写 display: block 或 visibility: visible 完全无效。浏览器对 <dialog></dialog> 的渲染逻辑是硬编码的：open 属性或 showModal()/show() 调用是唯二触发渲染的入口。CSS 无法绕过这一层控制。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 即使你用
!important覆盖，getComputedStyle(dialog).display仍返回none（除非已设置open） - 试图用
position: fixed+z-index手动模拟，会破坏showModal()后的自动居中逻辑，且 Safari 中可能引发子元素渲染异常 - 若需兼容无 JS 场景又想要基本交互，建议用
<dialog open></dialog>+ 外层包裹一个透明<div class="backdrop">，再通过媒体查询控制显隐 <h3>真要“默认弹窗”，JS 是绕不开的，且时机很关键</h3> <p>想一进页面就弹出带遮罩、锁焦点、支持 Esc 的对话框，必须用 JS。但直接在 <code><script></script>标签里写dialog.showModal()极易失败——DOM 还没挂载完，document.getElementById('xxx')返回null。- 确保执行时机：放在
底部、或监听DOMContentLoaded、或用defer属性 - 别在
document.write()或动态innerHTML插入后立刻调用，需确认元素已 append 到 document.body - 检查支持性：
if ('showModal' in HTMLDialogElement.prototype)，不支持时 fallback 到<div role="dialog"> + 手动焦点管理 <li>注意 Safari：iOS 16.4+ 才支持 <code>showModal()，旧版本静默失败，无报错也无提示
真实项目里，
open属性几乎只出现在两类地方：一是服务端渲染的降级 HTML（如邮件模板里的确认框），二是测试用的最小可运行示例。只要涉及用户交互闭环，就必须引入 JS 控制，而且不能只依赖属性。 - 确保执行时机：放在
