最近，围绕着老式的<details> 和<summary> 元素有很多讨论！我看到Lea Verou最近在推特上发表了一个关于元素display 行为的观察报告，然后就分裂成了更多的观察报告和人们的使用说明，包括重新讨论是否应该允许<summary> 包含互动元素。
有很多点需要连接，我将在这里尽我所能来做这件事。
我们可以改变嵌套在<details> 元素中的元素的显示吗？
在我正在构建的应用程序中，我使用
做面板，但遇到了一些尺寸上的怪事。
Flexbox:
t.co/noZvxAN35GG…:](t.co/pis0lPjvXk)
//t.co/pis0lPjvXkAt 起初我以为是个错误，但三个引擎都同意。的UA样式表中似乎没有任何东西可以解释这个问题。- Lea Verou (@LeaVerou)2022年8月28日
超级怪异!如果我们打开DevTools，用户代理样式表告诉我们<details> 是作为一个块元素显示的。
注意到所需的<summary> 元素和其中的两个额外的<div>s。我们可以覆盖display ，对吗？
我们可能期望的是，<details> 现在有一个明确的高度：40vh 和三行，其中第三行占用了前两行剩下的空间。像这样：
唉，但是第三行并没有......做......那个：
显然，我们要处理的是一个无法将网格行为应用于其网格项目的网格容器。但HTML规范告诉我们。
该
[details](https://html.spec.whatwg.org/#the-details-element)元素被期望呈现为一个块状的盒子。该元素预计也会有一个有两个槽的内部阴影树。(Emphasis mine)
再往后一点：
该
[details](https://html.spec.whatwg.org/#the-details-element)元素的第二个槽预计会将其[style](https://html.spec.whatwg.org/#attr-style)属性设置为"display: block; content-visibility: hidden;"。[details](https://html.spec.whatwg.org/#the-details-element)元素没有一个[open](https://html.spec.whatwg.org/#attr-details-open)属性。当它确实有[open](https://html.spec.whatwg.org/#attr-details-open)属性时，预计[style](https://html.spec.whatwg.org/#attr-style)属性将从第二槽中被移除。(强调是我说的)
所以，规范说，第二个槽--例子中的两个额外的<div>s--只有在<details> 关闭时才会被强迫成为块元素。当它打开时--<details open> --它们应该符合覆盖用户代理风格的网格显示...对吗？
这就是争论的焦点。我知道slots 默认设置为display: contents ，但是把嵌套的元素塞进槽里并取消对它们进行样式设计的能力似乎不妥。是规范的问题，即内容是槽，还是浏览器的问题，即我们不能覆盖它们的display ，即使它们在盒子树中？更聪明的人可以指点我，但这似乎是一个不正确的实现。
<details> 是一个容器还是一个互动元素？
很多人都在使用<details> 来切换菜单的打开和关闭。这是由GitHub推广的一种做法。
看上去很合理。规范肯定允许这样做。
该
[details](https://html.spec.whatwg.org/#the-details-element)元素代表一个披露小部件，用户可以从中获得额外的信息或控制。(强调是我的)
好吧，所以我们可能期望<details> 是容器（它有一个隐含的role=group ），而<summary> 是一个交互式元素，用来设置容器的open 状态。这是有道理的，因为<summary> 在某些情况下有一个隐含的button 角色（但没有相应的WAI-ARIA角色）。
但是，Melanie Sumner做了一些调查，不仅似乎与此相矛盾，而且得出结论，将<details> 作为一个菜单可能不是最好的办法。看看当<details> 在没有<summary> 元素的情况下被渲染时会发生什么。
CodePen嵌入回退
当它缺少一个<summary> ，它所做的正是规范所建议的--它做出了自己的。
该元素的第一个
[summary](https://html.spec.whatwg.org/#the-summary-element)元素的第一个子元素，如果有的话，代表细节的摘要或图例。如果没有子元素[summary](https://html.spec.whatwg.org/#the-summary-element)，用户代理应该提供自己的图例（如 "详细信息"）。(强调是我的)
梅兰妮通过HTML验证器进行了测试，结果令人惊讶!- 它是无效的。
因此，<details> 需要<summary> 。而当<summary> 缺少时，<details> 会自己创建，尽管它被当作无效的标记转达。当<summary> 在那里时，一切都很顺利，而且有效。
所有这些都导致了一个新的问题：**为什么<summary> 被赋予了一个隐含的button 的角色，而<details> 似乎是互动元素？**也许这是另一个浏览器实现不正确的案例？话又说回来，规范确实把两者都归类为互动元素。你可以看到这一切变得多么令人困惑。
无论如何，Melanie的最终结论是，我们应该避免在菜单中使用<details> ，这是基于辅助技术如何阅读和宣布包含互动元素的<details> 。该元素被宣布，但除此之外没有提到互动控制，直到你，呃，与 <details> 。只有到那时，才会公布类似链接列表的内容。
此外，折叠的<details> 内的内容被排除在页内搜索之外（除了在Chromium浏览器中，在写这篇文章时，它可以访问折叠的内容），使事情变得更加难以找到。
<summary> 应该允许互动元素吗？
这就是这个公开主题中提出的问题。我们的想法是，像这样的东西将是无效的。
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>
Scott O'Hara很好地总结了为什么这是个问题。
当用虚拟光标导航时，JAWS根本无法发现这个链接。如果通过Tab键导航到摘要元素，JAWS会宣布 "示例文本，按钮 "为该元素的名称和作用。如果再次点击Tab键，JAWS又会宣布 "示例文本，按钮"，尽管键盘焦点在链接上。
[...]
我还可以继续讨论不同的AT在摘要内容模型上的各种问题......但这只会使这个评论超出必要的范围。
Scott为纠正Chromium和WebKit中的这种行为开了票。谢谢你，Scott!
然而，它是有效的HTML。
斯科特在另一篇博文中做了进一步说明。role=button 例如，他解释了在<summary> ，这似乎是一个合理的修复，以确保它被辅助技术一致地宣布。这也将解决关于<summary> 是否应该允许互动元素的争论，因为按钮不能包含互动元素。唯一的问题是，Safari会把<summary> 作为一个标准的按钮，从而失去了它的expanded 和collapsed 状态。所以，正确的角色被宣布了，但现在它的状态却不是。 🙃
我们现在要去哪里？
在所有这些问题和不一致的情况下，你是否害怕使用<details>/<summary> ？我当然害怕，但只是为了确保其中的内容能够为用户提供正确的体验和期望。
我只是很高兴这些对话正在发生，而且是在公开场合进行的。正因为如此，你可以对Scott提出的关于如何定义<summary> 的内容模型的三个解决方案进行评论，为他的票据投上一票，同时报告你自己的问题和用例。希望我们越是了解这些元素是如何被使用的，以及我们期望它们做什么，它们就会被更好地实现。
