Skip to main content
Entry

Does the HTML details element solve progressively-enhanced disclosures?

The HTML details element continues to gain fans and get developers’ juices flowing. Scott Jehl recently tweeted:

I love the details/summary HTML elements. So versatile. My favorite part is being able to show a collapsed state from the start without worrying about potential operability issues if JavaScript fails to run (since its behavior doesn't need it).

Scott goes on to describe how creating disclosure widgets (controls that hide and show stuff) with resilience in mind is so much more difficult when not using <details> since it can require complex progressive enhancement techniques. At the very least these involve making content available by default in case JavaScript fails, then hiding it when the disclosure widget script loads successfully, ideally without a jarring flash of content in between.

Like Scott says, the <details> element is different because you can have the content collapsed (hidden) by default without worrying about JavaScript and workarounds since the hidden content can be toggled open natively. That‘s a real superpower… and also makes you wonder: how many different places and different ways might we use this super-element?

GitHub’s use of details #

A while back, GitHub caused a flutter by using details in lots of interesting ways. To do: add links

Zach Leatherman’s details-utils #

I’ve previously noted Zach Leatherman’s details-utils – a great example of using a web component to enhance an existing HTML element, in this case <details>. The enhancements include:

  • animated open/close
  • closed by default on narrow screens, open by default on wide
  • and more

And Zach has already used it on the navigation menus on jamstack.org and netlify.com, amongst other use cases.

A note of caution #

Alternative approaches #

Using a custom disclosure widget put together with JavaScript and ARIA is not the end of the world. In fact I recently tried my hand at a disclosure widget web component and early impressions are that the combination of fast, async ES modules plus native DOM discovery (which you get with web components) might alleviate the “flicker of content” issue I mentioned at the start.

Summing up #

So far I’ve been cautious about using details for more than simple cases but I’m starting to think the time may have come to take it further, possibly using Zach’s web component. A “hamburger” menu pattern might be a safe place to start… whereas I might not use it in situations where the “summary” (i.e. the toggle) needs to be more complex, for example on a subnavigation trigger which includes both a link and a button. When I do try it, it’d be great to employ some proper accessibility testing and get feedback.

External Link Bookmark Note Entry Search