使用 <details> 构建菜单可能是一个有趣的想法，但可能不适合实际投入生产。 参见 “有关 <details> 的更多详细信息” 以获取解释。
对于开始学习 JavaScript 的新手前端开发人员来说，最能让人感到有力量的事情之一就是 更改类。 如果你可以更改类，你就可以利用 CSS 技能来控制页面上的很多东西。 切换到一个类，以这种方式进行样式设置，切换到另一个类（或将其删除）并以另一种方式进行样式设置。
但是 HTML 元素也有切换功能！ <details>!
例如，它绝对是 构建手风琴 UI 的最快方式.
扩展这种基于切换的思路，用户菜单如果不是一个手风琴，还能是什么呢？ 模态框也是如此。 如果我们走这条路，我们可以让这些动态内容的 JavaScript 可选。 这正是 GitHub 在其菜单中所做的。
在 <details> 元素内部，GitHub 使用了一些 Web Components（需要 JavaScript）来完成一些额外的操作，但这些操作不是基本菜单功能所必需的。 这意味着该菜单具有弹性，并且在页面呈现时可以立即进行交互。
GitHub 的网络系统工程师 Mu-An Chiou 带头进行了这项工作，并有一个 关于此主题的演示文稿！
<details> 最糟糕的打击是它在 Edge 中的浏览器支持，但我猜我们很快就不必担心这个问题，因为 Edge 将使用 Chromium……很快吗？ 有人知道吗？
我不确定从语义上来说，这样做是否是一个好主意。
无论如何，我们可以使用 CSS focus-within 来丢弃脚本。
我也对语义学有同样的疑问。 虽然 W3C 提供了一个 示例，其中指出
<details>可用于“默认情况下隐藏某些控件”，但我不知道这是否描述了下拉菜单。可以从不同的角度去理解菜单，使其行为与
<details>标签的语义相一致。 例如，当用户菜单展开时，会显示用户操作的更多“详细信息”。 另一方面，未展开的用户菜单毫无用处，因为你无法与其交互，而展开以显示更多详细信息的项目似乎应该在其摘要形式下也具有用处。这种使用在何种程度上跨越了语义滥用的界限是一个很好的问题，考虑到无障碍性倡导者经常反对对类似标签（如
<em>和<i>）的滥用。我最初的评论中包含一个标记示例，但它被清理了……
在摘要元素上设置菜单角色将违反 ARIA 作者实践，即不与 HTML 语义相矛盾。
虽然尝试这个选项让我想知道 https://codepen.io/WW3/pen/pYqRgq?editors=1100
就像复选框 hack 一样，虽然这不是最好的方法，但它是一种简单而可靠的方式来实现一个简单的功能 [该功能应该现在在 html 中得到原生解决]，因此开发人员会将其用作切换菜单和其他内容的一种方式。
虽然 JS 通常是启用的，但对于那些没有启用 JS 的情况，CSS 和本机函数（如这个）是仍然有效的回退。 这里最重要的点是——为用户提供功能，即使整体功能受到……限制。
我同意使用 focus-within——最近一直在研究它，它可能成为“hacks”的另一种可行方案。 毫无疑问，其他东西也会出现来破坏这种方法！
18 个月前，
<details><summary>甚至没有在 https://inclusive-components.design/collapsible-sections/ 中提及。但是，浏览器/屏幕阅读器支持似乎得到了极大改善
– https://www.hassellinclusion.com/blog/accessible-accordions-part-2-using-details-summary/
– https://www.scottohara.me/blog/2018/09/03/details-and-summary.html