Tagged “details”
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.
Web components as progressive enhancement, by Cloud Four
By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.
Great article by Paul Herbert of Oregon’s Cloud Four. Using a web component to enhance an existing HTML element such as <textarea>
(rather than always creating a custom element from scratch) feels very lean, resilient and maintainable.
HTML: The Inaccessible Parts (daverupert.com)
Here’s Dave Rupert, frustratedly rounding up the accessibility shortfalls in browser implementations of native HTML elements.
I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up”. But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems.
Details and summary for no-JavaScript disclosure widgets
The fairly-recently added <details>
element is a great, native HTML way to toggle content visibility.
<p>Lorem ipsum dolor sit amet.</p><details>
<summary>System Requirements</summary>
<p>Requires a computer running an operating system. The computer
must have some memory and ideally some kind of long-term storage.</p>
</details><p class="end">Remember: built-in beats bolt-on, bigly!</p>
<!--
<details> is great but there are a few gotchas:
- Not totally flexible design-wise
- Unsuitable for accordions with multiple sibling elements unless you add some JS
- Unsupported in IE 11 (but content is still available)
-->:root { font-size: 110%; font-family: system-ui, -apple-system, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji";
}
input,
button {
font-size: inherit;
}
.end {
margin-top: 2rem;
}
See all tags.