本文翻译自外网文章《Dialogs, modality and popovers seem similar. How are they different?》，作者 Hidde de Vries 是一名自由职业前端、可访问性和系统设计专家，曾在荷兰政府、W3C (WAI)、Sanity.io 和 Mozilla 等组织工作。
Web 平台概念有时可能完全不同，但有时看起来又非常相似。语义、行为和特征可能都很难区分。由于一个新的 popover 属性正在被提出，所以这篇文章将探讨对话框(dialogs)、弹出窗口(popovers)、叠加层(overlays)和揭示小部件(disclosure widgets)之间的区别。 我们还将了解元素为 modal 时的含义。所有相关的概念看起来都非常相似，至少在我看来是这样的，那就让我们开始吧！
注意：在撰写本文时，popover它仍然是一个提案，仅作为实验提供。目前 popover 可以在以下环境测试：
- Chromium，在“实验性 Web 平台功能”标志的背后（计划于 2023 年 5 月底在稳定版 Chrome/Edge 中发布）
- Safari Technology Preview 技术预览版本：167
介绍
首先，词语存在一个问题：并不是所有人在任何时候的用意都是一样的。作为一名长期合同工，我经常改变工作环境——当我在不同的团队、公司、国家工作时，措辞都会不同。词语的含义会随着时间而改变，整个世界都是这样……这很正常！但就这些组件而言，解释的差异就可能会导致糟糕的用户体验。
在本文中讨论的许多概念都起源于操作系统：详细请参阅Apple 的人机界面指南、Microsoft 的“Win32”指南（旧版）和Windows 应用程序控件（更新版）。如果我们将它们与ARIA Authoring Practices Guide中的模式进行比较，我们会发现相似之处。一些相似之处仅在表面上，而另一些相似之处对辅助技术用户而言具有意义：一些 ARIA 组件的人体工程学设计与相应的操作系统人体工程学相似，无论好与坏。
但是，操作系统级指南或 ARIA Authoring Practices(APG) 并不是网页开发者寻找实现指导的最佳场所。操作系统级指南是针对操作系统的，APG 则是用来演示如何使用 ARIA 的 (而不是它是否被很好地支持)。
为了清晰起见，在本文中，我将引用网页中存在的 dialog、modality 和 popovers 的概念(注意：弹出窗口只是一种提议)，这些概念使用 HTML、CSS 和 ARIA 等语言进行描述。我的目的旨在与相关的网页标准保持一致，它们可能与其他地方和单个团队使用的定义略有不同。
接下来，我们将从组件具有的特征开始，例如模态(modality)、轻触关闭(light dismiss)、顶层存在(top layer presence)和背景(backdrops)。然后我们将讨论在网页或网络程序中同时使用这些特征时我们会得到什么：对话框、弹出窗口、覆盖物和揭示框。希望当我们首先详细讨论特性时，更容易区分组件本身。
特征
模态/惰性
一些系统会有一个名为“模态”（modal）的组件，但模态更多的是一种特性，而不是组件本身。
那么“元素是模态的”到底是意味着什么呢？简单来说，当模态组件打开时，它是唯一非惰性的存在。只有模态内容可以交互，页面或应用程序的其余部分都是惰性的。惰性内容是用户无法交互的内容。它只有在视觉方面存在，你无法通过 Tab 键切换、单击、滚动或通过辅助技术访问内容。
非模态元素称为非模态或无模态。
巴塔哥尼亚主页变暗，顶部有一个未变暗的 cookie 同意书，可选择接受所有 cookie 和 cookie 设置：
在这个例子中，变暗的背景表明在任何其他交互发生之前必须在接受和拒绝 cookie 之间做出选择。（注意：在实际网站上，滚动背景仍然有效，但这是不应该的）
并不是每个人都喜欢模态——作为一个 UI 概念，它们非常具有破坏性。只有当必要时，才应该使用该模式。如果你想问用户“您确定要删除所有这些吗？”的时候，可以利用这种具有破坏性的效果。但如果你想推广订阅注册或广告，则这种破坏性中断会不太友好。
在实现方面，你需要使除了模态元素之外的一切无效化。元素<dialog>（与 showModal()一起使用）可以实现，并是最好的选择。
如果您不能使用<dialog>或正在查看一个没有<dialog>的旧代码库，这里有一个区分模态内容和惰性(无效)内容的示例：
<body>
<div class="modal" role="dialog">
<!-- modal content -->
</div>
<div class="everything-else" inert>
<!-- everything else -->
</div>
</body>其核心在于一个元素是模态的，而其他元素则是惰性的，即无法被任何用户或操作访问。目前并非所有用户都会使用支持的浏览器inert（ github.com/WICG/inert ），所以最好使用 polyfill inert，如果没有inert或其 polyfill，你将需要添加 aria-hidden="true" 到模态之外的内容（以使其对辅助技术不可用）以及将非模态中的任何交互元素添加 tabindex="-1"。
仅仅通过将元素捕获焦点或添加背景并不能使其成为真正模态的。使用焦点捕获，你只能阻止用户通过键盘访问其余的内容。而添加背景，你只能在视觉上使其不可用。
轻度关闭 vs 显式关闭
需要考虑的另一个方面是用户如何关闭组件，以及是否受到其他元素的影响：这可以分为显式关闭和轻度关闭。
使用“显式关闭”，组件允许用户通过页面上的关闭按钮和键盘上的 Escape 键关闭它（当不确定时，最好同时添加两者）。
包含草稿推文和文本的撰写推文屏幕截图：显式关闭示例
显式关闭：如果我不想发送这条推文，我可以按关闭按钮或 Escape 关闭我看到的对话框
使用 "light dismiss" 的话，一个组件会在以下条件出现时自动消失：比如用户滚动、与其他元素交互或点击组件外部。默认情况下，用户通过 Tab 键离开元素时，light dismiss 不会触发 (但开发人员如果需要，可以添加此功能，详情可见 openui/open-ui#415 中的讨论)。
Light dismiss：如果字体选择器打开并且我单击正在编辑的文本，字体选择器将自动关闭
Light dismiss 是我们今天已经可以在 JavaScript 中构建的东西，很多网站都有 light dismiss 的组件。但是有了这个popover属性，浏览器会为你做这件事（如果你使用popover="auto"）。
顶层存在
默认情况下，如果多个元素被定位在同一位置，浏览器会按照 DOM 的顺序对它们进行绘制。在 DOM 中最先出现的元素会被绘制在第一位，随后的每个元素都在前一个元素之上，而 DOM 中的最后一个元素则被绘制在最后，位于最上面。利用 CSS 中的 z-index 属性，你可以根据具体情况决定其位置，使其偏离默认的顺序，这样你基本上可以决定自己的图层顺序。这一特性在 CSS 2.1 的一个附录中被定义为 "堆叠上下文"（详细描述）。
顶层(Top layer)是在上面描述的绘制过程之后绘制的，因此它里面的东西是在其他所有东西之上的。网页只有一个顶层，在最顶层图层中，元素按它们被添加到最顶层图层的顺序绘制 (因此移动它们涉及添加/重新添加它们)。
有时，开发人员会在 </body> 标记的前面(也就是DOM文档最下边)添加组件，以尝试确保它们被绘制在其他东西之上（假设没有任何元素的 z-index > 0）。
另一个 Top layer 的好处与 overflow 有关。如果你的弹出窗口在一个具有overflow: hidden 的元素中，它将会被截断。如果它被提升到最顶层图层，就不会发生截断。
背景
在某些情况下，为元素添加背景是有意义的。背景通常用于传达内容在后面是不可用的，以作交互提示。它可以用作帮助用户集中注意力的一种方式。
::backdrop 伪元素可以应用于最顶层图层元素，它允许你以任何您想要的方式设置背景样式。
受限焦点
有时焦点被限制 (或被困在) 特定元素中，这意味着如果焦点在这个元素上，无论按 Tab 还是 Shift + Tab 键，也永远不会切换到元素外面的元素。这种特性也被称为“键盘焦点陷阱”(keyboard focus trap)。这是使其他所有东西惰性化的副作用（这时<dialog>就发挥作用了）。(注意：将焦点困在一个元素中不使该元素成为模态元素，但如果它是真正的模态元素，则焦点无法移动到外部元素，因为外部元素不是可聚焦的)。
焦点陷阱应该是临时的，直到它所适用的元素关闭或取消 (如果它不是临时的并且无法使用键盘退出，则它将不符合 WCAG 2.1.2 标准)。
键盘可关闭/可折叠
如果内容可以被关闭或折叠，用户也应该能够只用键盘关闭或折叠它。
当内容可以关闭时，一种常见的模式是按下 Escape 键关闭内容。通常，关闭只在用户专注于组件内部时要受到限制，只有在用户专注于组件内部时才能关闭。如果有许多要关闭的东西，比如嵌套组件，则需要多次按下 Escape 键，以便从最内层到最外层的元素逐步关闭组件。
当内容可以折叠时，键盘用户应该能够使用与鼠标用户点击折叠内容的按钮相同的按钮。
主要模式
让我们看看一些常见的模式以及如何区分它们。
对话框 Dialogs
它是什么
Dialogs 是网页或应用程序中的一个组件，通常包含要执行的操作或某些任务（请参阅：HTML 规范中的 <dialog>）。它通常不是其他内容的自然流的一部分，因此它可能会 (并且通常会) 覆盖其他内容。MDN 将其描述为“子窗口”，ARIA 创作实践将其定义为“覆盖在主窗口或另一个对话窗口上的窗口”。
对话框通常在用户需要对某些事情进行提醒或选择时显示。你想要继续吗，是还是不是？如果你想打开一个新的文件，我们该怎么做？对你的当前文件进行保存或删除？
浏览器对话框 /confirm()
从规范上讲，对话框很像 window.confirm(),window.alert()和window.prompt()，这些功能被 HTML 标准列为“简单对话框”。但与这些浏览器内置的对话框不同，自定义对话框提供更多的灵活性——你可以将它们内部包含任何你希望的内容和样式。
对话框有一个名为“对话框”的role，当你使用 <dialog> 元素时，浏览器会自动为你分配。
您也可以通过 ARIA 创建对话框：将 role="dialog" 应用于元素 (例如<div>)。如果对话框是模态的，则在显示时添加 aria-modal="true"，并在对话框关闭时删除它。您需要自己完成所有模态工作 (焦点捕获、使其余内容无效等)。注意 :aria-modal 在 IE11 上不支持 (您的用户可能仍在使用该浏览器)，在 VoiceOver 中存在 aria-modal 问题，并且在 Narrator 中似乎不支持它。
您可以在对话框中包含一个以 method="dialog" 提交的表单。该表单将在提交时关闭对话框。
例子
插入链接对话框，其背后为暗色背景。 它有链接文本和 URL 字段，关闭对话框或添加链接的按钮
模态对话框：添加链接；当这个模态对话框打开时，它后面的任何东西都不能与之交互。
非模态对话框：当这个聊天小部件打开时，我仍然可以访问下面的表单和内容。
特征
对话框可以是模态的 (使用 dialog.showModal() 显示) 或非模态的 (使用 dialog.show() 显示)。为了避免产生歧义，你需要选择其中一种，并仅对每种对话框调用其中一个方法。
当使用 role="dialog" 的元素是模态时，浏览器将对话框外部的内容视为惰性，并防止键盘焦点到达对话框外部的网页内容 (如果使用 role="dialog" 则需要自己完成此操作)。如果使用 role="dialog" 的元素不是模态，则其他内容不会被视为惰性内容。这使得模态对话框变得更具破坏性，因此仅当必须时才使用它们。通常我们都不希望中断或干扰用户的流程。
只有当对话框是模态时，它们才会在顶部图层中显示 (且只有当使用 <dialog> 元素时，其他具有 role="dialog" 的元素才不会进入顶部图层)。
对话框必须具有可用的命名 (详情查看 WAI-ARIA 1.2,dialog role)。使用 aria-labelledby 属性将您的对话框与可见的标题或消息 (如果简短) 相关联。您也可以使用 aria-label，但与可见文本相关联是理想的，因为它创造了人们看到和辅助技术称为事物的一致性。
WAI-ARIA 规定，当使用 role="dialog" 时，应至少包含一个可聚焦的元素，并在对话框打开时将焦点移动到其中一个可聚焦的元素上。
当用户按下 Escape 键时，浏览器将关闭模态对话框。非模态对话框没有此默认行为，开发人员可以在需要时添加它。
警报对话框 Alert
WAI-ARIA 定义了一种特定的对话框类型，称为“警告对话框”。它们用于包含简短、重要的信息的对话框。它们的主要功能是警告用户，浏览器将通过触发系统警告事件向可用性 API 发送警告信息来实现这一点。它们是我们上面讨论的浏览器 alert() 对话框的 ARIA 等价物。
例子
- 当您没有与在线银行环境进行交互长达 10 分钟时，一个警告对话框将显示，并告诉您将在 5 分钟内退出登录，除非你点击“继续我的会话”按钮。
- 您正在编辑一些重要内容，并不小心按下了
Command + W快捷键，以关闭当前标签页。一个警告对话框出现，询问您是否真的想“离开”，不需要先“保存您的更改”吗。
特征
警告对话框始终是模态的，并且它们的焦点是固定的。它们也需要一个易于访问的名称。与对话框一样，如果有一个可见的标题，将标题的 ID 与警告对话框的 aria-labelledby 属性相关联。如果不存在明确的标题，也可以将 aria-label 添加到警告对话框上。
弹窗 Popovers
它是什么
Popover 是一个可以通过 popover 属性添加到任何元素上的行为集合 (类似于 tabindex 或 contenteditable)。它在 HTML 中被规范，并且有一个 polyfill。
关于为什么它是一个属性而不是元素：open-ui.org/components/…
该popover属性适用于以下 UI 组件：
- 位于其他页面内容之上的 UI 组件
- 并不总是可见的（只有发生与它们相关交互时可见），也被称为“短暂存在”或“短暂出现”
- 通常一次显示一个而不是同时显示多个。
与 <dialog> 不同，popover 没有内置的role (这就是它是一个属性而不是元素的部分原因)。它可以承担任何有意义的role，或者完全没有role。有时 popover 可以是 (无模式) 对话框，在这种情况下，可以使用 <dialog popover>。
popover 属性计划允许两种值，每种值都给出略有不同的特征集：
popover=auto: 轻量级关闭；当它打开时，它会强制关闭其他弹出窗口和提示（它的锚点除外）；popover=manual: 显式关闭（通过计时器、关闭按钮或其他脚本）；当它打开时，它不会强行关闭任何东西- （后续可能有更多类型）
全屏内容也会强制“auto”类型的 popover 关闭。
例子
一个 popover 的例子是当选择打开时显示的列表框 (对于<select>和<selectmenu>，因为它们目前被 Chromium 实现)。
以下是一些具有 popover 行为的常见组件示例:
- 日期选择器/日历小部件
- 工具提示和切换提示
- 教学/引导 UI（例如，在界面首次显示时指出界面的某些部分）
- 操作菜单（参见下面的示例），使用
role="menu"
还有一些弹出窗口需要用户关闭或自动关闭（如通知类 Toast）。
因此，确实存在许多不同的 UI 模式，它们可以要求“popover”行为。这就是为什么 popover 被提议不是作为一个 HTML 元素，而是作为一个属性，用于与最适合该模式的 HTML 元素/角色进行使用。对于动作菜单，那就是一个<div role="menu" popover>。一个提示符可以是<div role="tooltip" popover>(取决于上下文和它是什么)。无论如何，每个模式都有自己的 UX（用户体验）期望。
具有图像预览及其替代文本的 CMS 图像组件。 图片旁边是一个烤肉串按钮，从中可以展开一个名为替换的菜单，其中包含上传、浏览、下载、复制原始文件、复制 URL、清除字段等操作，最后一个是红色的：
这是一个用于更改图像的操作菜单，是一个弹出窗口。当您在其外部单击时，它会消失。
Twitter 上带有 fritz kola 瓶的图片，左下角是一个 ALT 徽章，从中展开一个弹出窗口，上面写着图像描述，描述瓶子，然后有一个大的 Dismiss 按钮
Twitter 的替代文本功能是弹出窗口的另一个示例（
实现存在可访问性问题
）
特征
Popovers 不是模态的。这是 弹出框 和 对话框 之间的另一个主要区别。因此，它们很少 (但不是不可能) 具有背景或焦点陷阱。
Popovers 可以具有“轻量级关闭”(light dismiss)行为，这意味着它们会自动关闭，除非设置了“手动”类型的。手动 popovers 可以像“通知”一样，通过计时器或手动按钮关闭。
Popovers 可以具有背景，用以遮挡它之外的内容。但这并不代表 popovers 就具有模态特性了。具有背景的 popovers 是有一些使用案例，但如果你的目的是想添加背景，则应该考虑使用模态对话框。
Popovers 可以将焦点困在其中，例如在复杂的小部件中，你希望避免人们不小心按 tab 离开控件。焦点陷阱并不能使 popovers 成为模态的，因为用户可以仍然访问页面上的其他内容，它只是在某些情况下可以提高可用性。
CMS 界面，发布按钮变暗，右下角有一个绿色框，上面写着“文档已发布”，该框右侧有一个带有关闭图标的按钮
几秒钟后自动消失的“Toast”通知，还有一个关闭按钮，以防您希望它现在消失（大多数Toast只是消失，这也很好；在任何一种情况下，它们的内容都应传达给辅助技术
www.w3.org/WAI/WCAG21/…
） .
Popovers 也可以不使用 JavaScript 进行打开、关闭和切换：通过在 HTML 中使用 <button> 标签并使用 popovertarget 属性指向 popover 的 ID，浏览器可以负责显示、隐藏和切换 popover。
一个例子：
<button
type="button"
popovertoggletarget="datepicker"
>Pick date</button>
<dialog popover id="datepicker"></dialog>在这个例子中，对话框通过使用 popover 属性变成了一个 popover，从而添加了 popover 的行为。点击按钮时将切换出 popover，因为 popover 的 ID 与按钮的 popovertarget 属性匹配。
按钮还可以设置为只显示或只隐藏，在这种情况下，使用 show 或 hide 操作 popovertargetaction。
为了使 popover 在页面加载时打开，请将 popover 设置为 defaultopen。这对于引导用户界面非常有用。
当 popover 打开时，将焦点移动到 popover，可以设置 popover 本身或其中的元素 autofocus 属性。正常情况下，该属性在页面加载时设置焦点。但是如果它在 popover 或其中使用，它将只在 popover 显示时设置焦点 (如果 defaultopen 被使用，则可能在页面加载时)。
为了定位弹出框，。据我今天的理解，它可以让我们自动将弹出框放置在最合适的位置，避免与窗口边缘发生碰撞。有点像今天的库，但内置于浏览器中。
为了定位弹出框，有一个非常令人兴奋的提议叫做CSS 锚点定位。据我理解，它将允许我们自动定位在最合适的位置，避免与窗口边缘发生碰撞。有点像 Popper 库今天所做的，一旦提议实现那么将可以在浏览器中直接使用。
如果焦点管理、定位、JavaScript-less 切换和轻量级关闭还不够，还有一项建议，可以使用 CSS 使 popover 在 [popover] 和 [popover]:popover-open 之间进行过渡。当然，您将使用 prefers-reduced-motion 遵循用户的运动设置(users' motion settings)。
覆盖 Overlays
Overlays 本身并不是一种组件，而是一种特性。通常，当开发人员谈到 overlays 时，他们指的是模态对话框。从字面上看，overlays 是放在其他事物之上的东西。弹出框和对话框都可以覆盖其他事物。
披露组件 Disclosure widgets
这些是什么
展示和隐藏元素的元素通常被称为“披露组件”，正如 Adrian Roselli 在他的关于各种 popover 类似的控制的文章中所描述的那样。这篇文章中几乎涵盖了所有的元素，这些都是可以展示和隐藏的元素。Adrian 在他的文章“披露组件”中对此进行了更详细的描述。
披露组件在 HTML 中以<details>/<summary>形式存在，但也可以通过<div>和适当的 ARIA 属性进行构建。这与<details>/<summary>并不完全相同。在Details/summary中，Scott O'Hara 建议这样做更为一致:
如果你的的目标是在不同的浏览器中创建绝对一致的披露组件行为，即确保所有的
<summary>都暴露为展开/收缩按钮，那么你最好使用 JavaScript 和必要的 ARIA 属性创建自己的披露组件。
但是，他补充道：你的 ARIA 披露组件将不会拥有<details>/<summary>的一些功能，例如页面内搜索 (Chromium 在<details>的内容中包含页面内搜索查询时触发其开放状态)。
披露组件并没有特定的role，但有一个 aria-expanded 属性为触发器和 aria-controls 连接触发器和触发它们的对象。当使用<details>/<summary>、<dialog>和 (未来)popover 时，浏览器会为你设置这些可用性属性。
例子
- 一个常见问题部分，其中折叠了答案，可以从问题中展开它们
- 可以展开单个行的表格（参见 Adrian Roselli 的Table with Expando Rows）
- “切换提示”，例如显示在复杂术语旁边的“信息”按钮，用于打开解释该词的工具提示
- “meganav”风格的导航，其中主要导航项打开更多导航
wikipedia content 在右侧有一个名为 Disability 的框，在该框下方所有部分都有显示按钮，除了前两个，它们已展开并且旁边有隐藏按钮
类别中部分的显示/隐藏功能（显示在右侧）是一个披露小部件
特征
有许多不同的东西可以被视为披露组件。它们共同点是它们由两个部分组成：一个是触发器元素，另一个是被触发的元素。
披露组件不会捕获焦点，没有背景，也不是模态的。它们通常使用触发器或特定的关闭按钮进行关闭或折叠。
常见问题
焦点应该移到哪里？
当模态对话框打开时，键盘焦点应该移动到默认操作。如果存在表单，很可能是第一个表单字段。如果存在多个按钮，可能是其中最不破坏性的一个，例如如果有“取消”和“确认”按钮，一个合理的默认选项可能是“取消”。
当模式对话框关闭时：如果用户触发它，将焦点移回触发器。浏览器会自动为<dialog>s 执行此操作。对于弹出窗口，它只在“有意义的地方”的情况下执行（请参阅弹出窗口解释器）。如果用户没有触发它，将它移动到 DOM 中较早的适当位置。
当模态对话框关闭时：如果用户触发了它，将焦点返回到触发器。浏览器会对<dialog>自动执行此操作。对于 popover，只有在“有意义”的情况下才会执行 (请参考 popover 解释器)。如果用户没有触发它，将焦点移动到 DOM 中适当的位置。
对于所有其他组件（非模态对话框、弹出窗口或披露），预期的焦点管理因情况而异。Popup Explainer 关于焦点的部分描述了一些这样的情况。
所有的弹出窗口都是对话框吗？
让我们区分三种我们可能用“dialog”指代的事物:
<dialog>元素，一个具有内置对话框角色和对话框行为和可能性的元素 (例如，你可以在其上运行 show() 和 showModal() 方法)。
元素 role="dialog": 该 role 属性的 dialog 值为其赋予对话框角色，但除此之外，它什么都不带，需要为其添加自己的行为。
有时，popovers 使用<dialog>元素或具有 role="dialog" 的元素。但并不是所有 popovers 都使用这些元素。例如，列表框、菜单、Tooltips、网格、链接列表都可能需要 popover 行为，但不需要对话框角色或<dialog>元素。
所有对话框都是弹出窗口吗？
不，只有非模态对话框在概念上才是 popover(您今天可以使用<dialog>/role="dialog"来实现它们)。当 popover 功能在浏览器中稳定且得到广泛支持时，使用<dialog popover>是有道理的，如果您希望您的非模态对话框出现在表层图层并利用浏览器提供的轻击关闭功能，那么这就是正确的方法。相比之下，模态对话框并不具有 popover 所具有的特征。
一些例子：
国家选择器
您正在为在线商店构建结账表单。在一个字段中，用户需要选择一个国家。他们最终必须选择这个国家，因为它是必需的字段。然而，当他们选择国家时，他们可能想浏览其他内容，或者先弹出信用卡信息。他们可能需要查看标签以确定您是否需要出生国或居住国。最好采用非模态对话框，因为用户可能想查看其他内容。
定义弹出窗口
您正在构建一个可切换提示符，用于在内容中显示复杂单词的定义。当定义图标被点击时，它会打开。您的用户可能想滚动到其他地方、阅读其他内容或执行其他操作。最好保持这种模式为非模态。
游戏结束
用户已经玩了几个游戏关卡，但失败了，现在出现了“游戏结束”的对话框。他们无法继续游戏。游戏已经结束，并且出现了一个对话框来告诉他们这个消息。他们没有其他可以交互的东西了。这就是模态对话框。
跟踪同意
您正在构建一个对话框，询问用户是否愿意同意您跟踪他们。您的访客位于一个法律规定未经同意不得进行跟踪的地区。在这种情况下，与其他任何屏幕交互都没有意义，因此将对话框设置为模态modal是有道理的。
弹出式导航
您正在构建一种“弹出式导航”。它在视口一侧打开，并在其打开时置于其他内容之上。当用户打开它时，这是他们唯一想要看到的东西吗？这是一个棘手的问题，我感觉模态对话框可以工作，非模态对话框也可以工作。
总结/结论
最后，总结一下：
组件的模态性是一种状态，只有在这种状态下，该组件才能使用。当某物是模态的，其他一切都变得无效：阻止任何方式访问，不可聚焦，通常被背景层所遮盖。将某物设置为模态是一项重大决定，应该谨慎使用。
对话框可以是模态或非模态的 (也称为非模式对话框)。popovers 是由 Open UI 提出的一种新方法，用于构建非模态对话框，它具有特定的行为和特征，例如表层存在、无需 JS 的可 toggle 性和浏览器提供的轻击关闭。与<dialog>不同，popover 没有内置的role：作为一名开发人员，您可以将 popover 属性添加到语义上最相关的元素上。
本文中提到的大部分 UI 模式都适用于 overlay 的定义：可以位于其他内容之上的内容 (所有对话框和 popover)。它们也经常适用于 disclosures 的定义，即一种模式，其中一件事打开另一件事。
这就是全部！是的，我写了整个长长的文章关于定义，最终得出结论，这些确实是相同模式的不同名称。但是，它们之间有微妙的区别。希望本文有助于您更清楚地区分这些模式。
原文链接：Dialogs, modality and popovers seem similar. How are they different?
以上就是文章的全部内容，感谢看到这里！如果觉得写得不错，对你有所帮助或启发，可以点赞收藏支持一下，也欢迎关注，我会更新更多实用的前端知识与技巧。我是茶无味de一天，希望与你共同成长~
