很多人都在喋喋不休 <details> 和 <summary> 最近的元素！ 我看见 Lea Verou 最近在推特上发表了一篇评论 关于元素的 display 行为，并且从人们那里分裂成更多的观察和使用说明，包括 重新讨论 取决于 <summary> 是否应该允许包含交互元素。
有很多点要连接，我会在这里尽我所能做到这一点。
我们可以更改嵌套在 <details> 元件？
超级诡异！ 如果我们打开 DevTools，用户代理样式表会告诉我们 <details> 是一个显示为块元素。
注意必填项 <summary> 元素和两个额外的 <div>s 在里面。 我们可以覆盖 display， 对？
我们可能期望的是 <details> 现在有一个明确的高度 40vh 和三行，其中第三行占用前两行剩余的空间。 像这样：
呃，但是第三排没有……做……那个。
显然，我们正在处理的是一个网格容器，它无法将网格行为应用于其网格项。 但是 HTML 规范告诉我们：
details元素是 预计呈现为 方块盒. 该元素还有望具有内部 影子树 有两个 插槽.（强调我的）
稍后：
details元素的第二个 插槽 预计将有其style属性设置为“display: block; content-visibility: hidden;“ 当。。。的时候details元素没有open属性。 当它确实有open属性，style属性预计会从第二个中删除 插槽.（再次强调我的）
所以，规范说第二个插槽——另外两个 <div>示例中的 s — 仅在以下情况下被强制转换为块元素 <details> 已经关了。 打开时—— <details open> — 它们应该符合覆盖用户代理样式的网格显示……对吗？
这就是辩论。 我明白了 slots 被设置为 display: contents 默认情况下，，但是将嵌套元素插入插槽并删除它们的样式似乎已关闭。 内容是插槽是规范问题，还是我们无法覆盖它们的浏览器问题 display 即使它们在盒子树中？ 更聪明的人可以启发我，但这似乎是一个不正确的实现。
Is <details> 容器还是交互元素？
很多人都是 运用 <details> 切换菜单 打开和关闭。 这是一种练习 由 GitHub 推广.
似乎有道理。 规范肯定允许它：
detailselement 代表 一个披露小部件，用户可以从中获取更多信息 或控制.（强调我的）
好的，所以我们可能会期望 <details> 是容器（它有一个 含蓄 role=group) 以及 <summary> 是一个交互式元素，用于设置容器的 open 状态。 有道理，因为 <summary> 有隐含的 button 角色 在某些情况下（但没有相应的 WAI-ARIA 角色）。
但是， 梅兰妮萨姆纳做了一些挖掘 这不仅似乎与此相矛盾，而且得出的结论是，使用 <details> 作为菜单可能不是最好的。 看看什么时候发生 <details> 没有呈现 <summary> 元件：
它完全符合规范在缺少 <summary> - 它自己制作：
最快的
summary元素的子元素， 如果有的话, 代表 详细信息的摘要或图例。 如果没有孩子summary元素，用户代理应该提供自己的图例（例如“详细信息”）。（强调我的）
Melanie 通过一个 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>使用虚拟光标导航时，JAWS 根本无法发现该链接。 如果通过 Tab 键导航到摘要元素，JAWS 会宣布“示例文本，按钮”作为元素的名称和角色。 如果再次按 Tab 键，即使键盘焦点位于链接上，JAWS 也会再次宣布“示例文本，按钮”。
[...]
对于不同的 AT 在摘要内容模型方面存在的各种问题，我可以继续讨论更多......但这只会将这个评论扩展到超出必要的范围。 tldr; 摘要内容模型为使用 AT 的人产生了非常不一致的，有时甚至只是平淡无奇的体验。
斯科特开票以纠正这种行为 铬 和 WebKit的. 谢谢，斯科特！
然而，它是有效的 HTML：
斯科特走得更远 单独的博客文章. 例如，他解释了如何打耳光 role=button on <summary> 似乎是一个合理的解决方案，以确保辅助技术始终如一地宣布它。 这也将解决关于是否 <summary> 应该允许交互元素，因为 按钮不能包含交互元素. 唯一的问题是 Safari 然后处理 <summary> 作为一个标准按钮，它失去了它的 expanded 和 collapsed 状态。 所以，正确的角色被宣布了，但现在它的状态不是。 🙃
我们现在去哪？
你害怕使用 <details>/<summary> 所有这些问题和不一致？ 我当然是，但只是为了确保其中的内容为用户提供正确的体验和期望。
我很高兴这些对话正在发生并且它们是公开进行的。 因此，您可以评论 Scott 提出的关于内容模型如何 <summary> 已定义，支持他的票，并在您处理时报告您自己的问题和用例。 希望我们越了解这些元素的使用方式以及我们期望它们做什么，它们的实施就越好。
