不支持侧边抽屉布局，因其原生仅支持居中模态弹出；需禁用默认定位、脱离文档流、接管开关逻辑才能强行实现，但维护成本高且可访问性差；推荐用+aria+css动画+焦点管理替代。
dialog 标签默认不支持侧边抽屉布局
<dialog></dialog> 是语义化模态对话框元素，浏览器原生实现仅支持居中弹出、带 backdrop、可 showModal() 或 show()。它没有内置的「从右/左滑入」「固定侧边」「不遮挡主内容」等抽屉行为。强行用 <dialog></dialog> 实现侧边抽屉，本质是绕过其设计意图，需大量 CSS 覆盖和 JS 干预，反而增加维护成本。
强制用 dialog 实现侧边抽屉的关键 hack 步骤
若因合规或框架约束必须用 <dialog></dialog>，需同时满足三个条件：禁用默认居中、脱离 document flow、接管打开/关闭逻辑。否则会出现闪动、滚动穿透、焦点丢失等问题。
- 用
position: fixed+top: 0; right: 0;覆盖默认定位，宽度设为width: 320px（或自适应） - 显式设置
margin: 0和transform: none，否则 Chrome 会叠加居中 transform - 调用
show()（非showModal()），避免触发 backdrop 和 focus trap；手动添加半透明遮罩层（<div class="drawer-backdrop">）并控制 z-index <li>监听 <code>click外部区域时，先dialog.close()，再移除 backdrop —— 直接remove()会导致close事件不触发
<dialog id="sidebar-drawer" style="position: fixed; top: 0; right: 0; width: 320px; height: 100%; margin: 0; transform: none;"><div class="drawer-content">...</div> </dialog>
比 dialog 更合适的技术选型
侧边抽屉的核心诉求是「可控进出动画」「独立容器上下文」「无障碍焦点管理」，<dialog></dialog> 在这些点上既不轻量也不灵活。实际项目中更推荐：
- 用
<aside></aside>+ ARIA 属性：role="dialog"、aria-modal="true"、aria-hidden切换，配合inert属性禁用背景交互 - CSS transitions 配合
transform: translateX(100%)/translateX(0)控制位移，比left/right性能更好 - 使用
focus-trap库（或手写focusout+focusin逻辑）管理键盘焦点，比依赖<dialog></dialog>的原生 trap 更稳定 - 若需服务端渲染兼容，避免依赖
showModal()—— 它在 Safari 15.4 之前不支持，且 SSR 中无法初始化状态
容易被忽略的可访问性细节
无论用 <dialog></dialog> 还是 <aside></aside>，侧边抽屉一旦打开，必须确保屏幕阅读器能感知状态变化，且焦点不会“掉出”抽屉。这点常被跳过：
- 打开时，用
element.focus()主动聚焦抽屉内第一个可聚焦元素（如button.close），不能依赖 autofocus ——<dialog></dialog>的 autofocus 行为在非showModal()下不可靠 - 关闭后，焦点必须回到触发按钮（
triggerButton.focus()），否则用户按 Tab 会迷失在页面末尾 - 用
aria-labelledby关联标题，而非仅靠视觉<h2></h2>—— 否则 VoiceOver 可能读不出抽屉目的 - 动画过程中禁用 pointer-events 不够，需同步设
aria-hidden="true"给背景内容，否则 NVDA 仍可能朗读不可见区域
抽屉不是视觉动效问题，而是交互边界问题。把容器位置、焦点流、语义声明、动画时机这四件事对齐了，用什么标签反而没那么重要。
