Using <details> for a menu may be an interesting idea, but perhaps not something to actually ship in production. See “More Details on <details>“ for an explanation.
One of the most empowering things you can learn as a new front-end developer who is starting to learn JavaScript is to change classes. If you can change classes, you can use your CSS skills to control a lot on a page. Toggle a class to one thing, style it this way, toggle to another class (or remove it) and style it another way.
But there is an HTML element that also does toggles! <details>!
For example, it’s definitely the quickest way to build an accordion UI.
Extending that toggle-based thinking, what is a user menu if not for a single accordion? Same with modals. If we went that route, we could make JavaScript optional on those dynamic things. That’s exactly what GitHub did with their menu.
Inside the <details> element, GitHub uses some Web Components (that do require JavaScript) to do some bonus stuff, but they aren’t required for basic menu functionality. That means the menu is resilient and instantly interactive when the page is rendered.
Mu-An Chiou, a web systems engineer at GitHub who spearheaded this, has a presentation all about this!
<details> is its browser support in Edge, but I guess we won’t have to worry about that soon, as Edge will be using Chromium… soon? Does anyone know?
I am not sure semantically it’s a good idea to do .
Anyhow, we can dump scripting by using CSS focus-within
I have had that question regarding semantics, too. Although W3C does provide an example which says
<details>can be used to “hide some controls by default”, I’m not sure if that describes dropdown menus.Its possible to think of a menu in ways that reconcile its behaviour with the semantics of a
<details>tag. For example, a user menu when expanded shows more ‘detailed’ options for user actions. On the other hand, the user menu un-expanded is worthless since you can’t interact with it, whilst a item that expands more details about itself seems like it should be useful in its summarised form.At what point this sort of use crosses into abuse of semantics is a good question, considering how often accessibility advocates speak out against misuse of even similar tags like
<em>and<i>My original comment included a markup example but it was sanitized…
Setting a menu role on the summary element would be a violation of the ARIA authoring practice of not contradicting HTML semantics.
Though playing with this option makes me wonder https://codepen.io/WW3/pen/pYqRgq?editors=1100
Like the checkbox hack, while it’s not the best approach, it’s a simple and robust way to do a simple feature [that should have been resolved natively by now in html], so developers will use it as a way to toggle menus and other content.
While JS is commonly enabled, for those instances where it isn’t, CSS and native functions like this are the fallbacks that still work. And that’s the important point here – providing the user with functionality, even if overall capabilities are… constrained.
I agree with the focus-within usage – been looking into that myself recently and it could be a viable alternative to ‘hacks’. No doubt something else will crop up to foul that approach up too!
18 months ago,
<details><summary>was not even mentioned in https://inclusive-components.design/collapsible-sections/.However, it appears that browser/screen-reader support is much improved:
– https://www.hassellinclusion.com/blog/accessible-accordions-part-2-using-details-summary/
– https://www.scottohara.me/blog/2018/09/03/details-and-summary.html