原文：Top layer troubles: popover vs. dialog 作者：Stephanie Eckles 日期：2025年12月1日 翻译：田八
来源：前端周刊
你是否曾尝试通过设置 z-index: 9999 解决元素层级问题？如果是，那你其实是在与一个基础的CSS概念 ------层叠上下文------ 斗争。
层叠上下文定义了元素在第三维度（即"z轴"）上的排列顺序。你可以把z轴想象成视口中层叠上下文根节点与用户（即通过浏览器视口观察的你）之间的DOM元素的层级。
一个元素只能在同一层叠上下文中重新调整层级。虽然 z-index 是实现这一点的工具，但失败往往源于层叠上下文的变化。这种变化可能通过多种方式发生，例如使用固定定位（fixed）、粘性定位（sticky）元素，或是将绝对定位（absolute）/相对定位（relative）与 z-index 结合使用等，MDN 上列出了更多原因。
现代网页设计有一个"顶层"特性，它保证使其位于所有其他层叠上下文的最顶层。它覆盖整个视口，不过顶层中的元素实际可见尺寸可能更小。
将元素提升到顶层，可使其摆脱原本所在的任何层叠上下文。
虽然顶层直接解决了一个与CSS相关的问题，但目前还没有属性可用于将元素提升到顶层。取而代之的是，某些元素和特定条件可以访问顶层，例如通过 <div> 标签显示的原生对话框 showModal() 和被指定为 Popover 的元素。
Popover API是一项新推出的 HTML 功能，它允许你声明式的创建非模态覆盖元素。通过使用 Popover API 用来摆脱任何层叠上下文，这是它的一个理想特性。然而，在急于选择这种原生能力之前，需要注意一个潜在的问题。
场景设定
想象一下，在2025年的网络世界：你的网页应用包含一个通过"Toast"消息显示通知的服务。你知道的，就是那些通常出现在角落或其他不太可能遮挡其他用户界面（UI）位置的弹出消息。
通常，这些Toast通知通常用于实时提醒，比如保存成功，或者表单提交失败等错误提示。它们有时有时间限制，或者包含如关闭按钮这样的关闭机制。有时它们还包含额外操作，例如"重试"选项，用于重新提交失败的工作流。
既然您的应用紧跟时代潮流，你最近决定将Toast升级为使用Popover API。这样你就可以将Toast组件放置在应用的任何结构中，而无需为了解决层叠上下文问题而采用一些变通方法。毕竟，Toast必须显示在所有其他元素之上，因此通过 Popover 实现顶层访问是明智之举！
你发布了改进版本，并为自己的工作感到自豪。
发布的当周晚些时候，你收到了一份紧急错误报告。不是普通的错误报告，而是一个可访问性违规报告。
Dialog vs. popover
你的应用很新潮，你之前也升级使用了原生HTML对话框。那是一次很棒的升级，因为你用原生 Web 功能取代了对 JavaScript 的依赖。这也是你兴奋地将Toast也升级为使用Popover的另一个原因。
那么，错误是什么呢？一位键盘用户正在使用一个包含对话框的工作流程，对话框打开期间，后台进程触发了一个弹出式通知。该通知提示存在错误，需要用户进行交互。
当这位键盘用户试图将焦点切换到Toast上时，出现了错误。他们虽然在视觉上能看到Toast显示在对话框背景之上，但焦点无法成功进入Toast，而是意外地跳到了浏览器UI上。
你可以在这个CodePen示例中亲自体验这个错误，使用Tab键，你会发现你永远无法访问到Toast。你也可以尝试使用屏幕阅读器，会发现虚拟光标也无法进入Toast。
如果你能够点击弹出框，可能会觉得至少点击操作是可行的。但很快我们就会发现，事情并非如此。
为什么Toast弹出框无法访问
虽然顶层可以超越标准的层叠上下文，但顶层中的元素仍然受分层顺序的影响。最近添加到顶层的元素会显示在之前添加的顶层元素之上。这就是为什么Toast在视觉上会显示在对话框背景之上。
如果弹出框在视觉上可用，那为什么通过键盘或屏幕阅读器的虚拟光标却无法访问呢？
原因在于弹出框与 模态 对话框之间存在竞争关系。当通过 showModal()方法启动原生HTML对话框时，对话框外部的页面会变为 惰性状态 。惰性状态 是一种必要的可访问性行为，它会隔离对话框内容，并阻止通过Tab键和虚拟光标访问背景页面。
这个错误是由于Toast弹出框是背景页面DOM的一部分。这意味着由于它位于对话框DOM边界之外，所以也变成了惰性状态。
但是，由于顶层顺序的原因，因为它是在对话框打开后创建的，所以在视觉上，它被放置在对话框的顶部，这一点可能会让你感到困惑。
如果你以为点击弹出框就能关闭它，实际上并非如此，尽管弹出框确实会消失。真正发生的情况是，你触发了弹出框的 轻触关闭 行为。这意味着它关闭是因为你实际上点击了它的边界之外，因为对话框捕获了点击操作。
所以，虽然弹出框被关闭了，但"重试"按钮实际上并没有被点击，这意味着任何关联的事件监听器都不会被触发。
即使你创建了一个自动化测试来专门检查当对话框打开时Toast的提醒功能，该自动化测试仍可能出现误报，因为它触发了对Toast按钮的编程式点击。这种伪点击错误地绕过了由于对话框导致页面变为惰性状态所引发的问题。
重新获得弹出框访问权限
解决方案有两个方面：
- 将弹出框(popover)在DOM中实际放置在对话框(dialog)内部。
- 确保使用
popover="manual"，以防止对话框内的点击操作过早触发弹出框的轻触关闭。
完成这两步后，弹出框现在既在视觉上可用，又可以通过任何方式完全交互。
经验教训与额外考虑
我们了解到，如果你的网站或应用有可能同时显示弹出框和对话框，并且它们有独立的时间线，那么你需要想出一种在对话框内启动弹出框的机制。
或者，您可以选择在对话框关闭之前禁用后台页面弹出窗口。但如果通知需要及时交互，或者对话框内容有可能触发 Toast 提示，则此方法可能并不理想。
除了可见性和交互性之外，您可能还需要考虑另一个问题：弹出窗口是否需要在对话框关闭后继续保持打开状态。也就是说，即使对话框关闭，弹出窗口也需要保持打开状态，例如继续等待用户执行操作。
虽然我非常支持使用原生平台功能，而且我认为弹出框（popover）尤其出色，但有时冲突是无法完全避免的。事实上，您可能已经遇到过类似的问题，即模态对话框的惰性行为。因此，本文的主要目的是提醒您，如果同时显示背景弹出框和模态对话框，可能会出现问题，因此不要完全放弃之前自定义的弹出框架构。
如果这个问题目前或将来会影响到你的工作，请关注这个HTML问题，其中正在讨论解决方案。
关于斯蒂芬妮·埃克尔斯
Stephanie Eckles 是 Adobe Spectrum CSS 的高级设计工程师，也是 CSSWG 的成员，同时还是 ModernCSS.dev 的作者。Steph 拥有超过 15 年的 Web 开发经验，她乐于以作家、研讨会讲师和会议演讲者的身份分享这些经验。她致力于倡导无障碍设计、可扩展 CSS 和 Web 标准。业余时间，她是两个女儿的妈妈，喜欢烘焙和水彩画。
博客：ModernCSS.dev Mastodon：@5t3ph
译者注：
这两个都是新特性，具体内容可参考MDN