Tagged “details”


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.

Read my notes / Visit original


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.

Read my notes / Visit original

Note · 12:00 AM · Glasgow

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>

<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>

<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";


button {
font-size: inherit;

.end {
margin-top: 2rem;

See all tags.

External Link Bookmark Note Entry Search