But there is an HTML element that also does toggles!
<details>! For example, it’s definitely the quickest way to build an accordion UI.
Mu-An Chiou, a web systems engineer at GitHub who spearheaded this, has a presentation all about this!
We went all in on details to turn a lot of things interactive without JS. There is also https://t.co/SFXtkNzIbZ, and here is a talk I gave on leveraging the power of details, which mentions the CSS trick :) https://t.co/DmX8opvi4z
Happy to talk/share about about any of these!
— Mu-An Chiou (@muanchiou) February 1, 2019
The worst strike on
<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
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: