一瞥 来自 Christian Kozalla 关于 <dialog> HTML 元素，以及如何使用它来创建一个外观漂亮且可访问的模态。
我被 <dialog> 元素吸引，因为它是一个“你免费得到很多”的元素（甚至比备受喜爱的 <details> 元素还要多），而且模态可访问性很容易做错（例如，焦点捕获），所以有一个本机元素提供这种功能，看起来…很棒。::backdrop 尤其酷。
但这真的是太好了吗？ <dialog> 的支持还没有很稳固，Safari 还没有支持它。Christian 提到了 来自 Google 的 polyfill，它肯定有助于将基本功能带到不支持它的浏览器。
主要问题是在屏幕阅读器上的实际测试。 Scott O’Hara 有一篇文章，“有一个打开的对话框，” 该文章最近（2021 年 10 月）更新过，他最终说，“[…] dialog 元素及其 polyfill 不适合在生产中使用。” 我不怀疑 Scott 的测试结果，但由于大多数人只是不理会可访问性，而自己构建模态体验，我想知道如果更多人只是使用 <dialog>（以及 polyfill）是否会更好。 更高的使用率可能会引发更多浏览器的关注和改进。
从今天开始，dialog 元素在 Safari TP 134 中得到支持：https://webkit.org/blog/12033/release-notes-for-safari-technology-preview-134/
我想知道要到什么时候才能稳定？ 我今天升级到 Monterey 了，所以最糟糕的情况就是……下个操作系统之后？ 我很兴奋，我想我们可以将来真正地使用它。
是的，我认为这不可能是巧合…
很高兴看到进展
完全同意，使用次数越多，就会越暗示浏览器我们想要它。
另外，通过一些额外的 JS 添加丢失的可访问性可以解决丢失的部分，尽管如果这是 Dialog 的一部分会更好。
不会。 但是，这样做会故意排除用户。
Scott 提供了 正确做法的示例。 建议使用明显不可访问的模式，而不是引导开发人员使用可访问的模式，这是在招致 WCAG（以及法律）风险。
历史表明情况并非如此。
例如，即使其他浏览器都支持，Chrome 仍在继续拖延专家关于 对话框打开时默认焦点应该放在哪里 的建议。 Chrome 的三年（3 年）拖延策略及其对 WHATWG HTML 的巨大影响本身就是一个可访问性障碍。
更不用说，微软的可访问性团队必须参与才能使 Chrome 中的默认焦点轮廓通过 WCAG 检查（2019 年）。 更不用说，自从 WCAG 1.0 在 1999 年要求以来，没有一个浏览器继续将以新窗口打开的链接作为可访问性层的一部分公开 公开。 等等。
对于开发人员来说，更负责任的做法是使用可访问的模式。 那些在标准方面工作的人可以使用这些案例来证明浏览器存在缺陷，并施加压力。 而且不会排除用户。
我强烈反对这种看法。 有意发布不可访问的代码会剥夺人们的访问权。 如果那个模态可以帮助你买杂货、预约医生或签署同意书怎么办？
问题在于浏览器级别的能力主义，即已知可访问性问题被优先考虑为新的闪亮功能。
无论如何，你都必须使用 div 来构建相同的内容。 我只是让我的使用 dialog with dialog[open=”true”] {…} （以及更多）。 随着支持的增加，开始用本机代码替换专有代码。 人们还认为，即使是模态，也是如此困难，以至于你必须为此使用插件。 它基本上只是一个 CSS 块和循环制表符。 并不难！
不幸的是，
<dialog>实际上真正好的东西，即 z-index 处理、焦点管理和背景支持，只能通过命令式的.showModalAPI 来实现。open属性与正常的.show方法相同，并将对话框呈现为正常的、类似<div>的元素。因此，它在声明性框架中基本没有用，
<dialog open modal />会很好…就像大多数其他很酷的本机 HTML 元素一样，它非常… 缺乏。
背景不会继承 CSS 变量（例如颜色）
你必须通过重置来摆脱填充和边框（无论出于何种原因）
打开/关闭是通过 display block/none 完成的，因此无法通过过渡来动画显示外观。 你必须手动更改所有内容才能使过渡成为可能。
背景不会隐藏，而是在隐藏时被移除，因此即使你重写了对话框以允许过渡，背景也不会与过渡一起使用。 你必须使用 JS 和动画，或者使用一个技巧，并为对话框提供一个巨大的盒阴影。
这些只是我在 2 个小时内发现的内容。 这些东西是谁设计的？ 如果这是一个组件，我会将其退回，并附上一个错误修复列表！ 天哪。