The Cascade is a blog about the past, present, and future of CSS.

Howdy—Robin Rendle here.

We’re living through a golden age: CSS was once a language that was easy to make fun of but has now transformed into a serious and expressive toolkit for building visual interfaces. Although making fun of CSS was always lame, today, in 2024, it shows a deep lack of curiosity. The train has left the station. CSS rules. Get with the program.

But this didn’t happen randomly. Thousands of dedicated, smart folks have worked tirelessly over decades to get us to this point where CSS is—in this humble blogger’s opinion—the best design tool ever made. Every day some new super power is unlocked for us in browsers and with each new power the web becomes a better place, thanks to them.

So this blog exists to keep me in the loop and somewhat up to date with everything that’s possible with CSS but also it’s a reminder to celebrate the people doing the hard work building these tools for us.

You can subscribe to The Cascade via RSS, shoot me an email if you absolutely must, or follow the feed. This project is directly supported by readers and the membership program.

Right now the newsletter is taking a bit of a break whilst I figure out a healthy publishing cadence, but you can subscribe below:

Popover API

Una Kravets has the scoop on the Popover API being fully supported in browsers:

It's happening! One of the features I am most hyped about has just landed across all modern browsers and is officially a part of Baseline 2024. And this feature is the Popover API. Popover provides so many awesome primitives and developer affordances for building layered interfaces like tooltips, menus, teaching UIs, and more.

“Baseline” is a way of measuring browser support that I had somehow managed to skip right over when it was announced last year. But anyway, back to Una’s post: Popover is real neat because you don’t have to worry about z-index or focus management, and using the API is as simple as writing some good ol’ HTML:

<button popovertarget="mypopover">Toggle the popover</button>
<div id="mypopover" popover>Popover content</div>

I like this! This syntax feels very much like invokers and ya know that I love those. But one question I had when reading Una’s post was this: when and how should I use the Popover API?

Thankfully, Hidde de Vries has collected a bunch of examples from menus and popover lists to teaching UIs and mega-navs that’s worth looking at in his post about Popover semantics. Hidde also reminds me that the title attribute exists which makes things even more complicated. And it looks like there’s rumblings about being able to customize the styles of that in the future which I would LOVE.

Another confounding question here: when should I use [popover] and when should I reach for <dialog>? MDN recommends that this decision should be based on whether you need the content of the page to “inert” whilst this thing is active:

Popovers created using the Popover API are always non-modal. If you want to create a modal popover, a <dialog> element is the right way to go. There is significant overlap between the two — you might for example want to create a popover that persists, but control it using declarative HTML. You can turn a <dialog> element into a popover (<dialog popover> is perfectly valid) if you want to combine popover control with dialog semantics.

Huh! So you can write something like this:

<dialog popover id="mypopover">This is some content</dialog>
<button popovertarget="mypopover">Open</button>

That’s handy. But wait, okay. Now I’m really, extremely confused—when should I use title versus popover versus dialog again? Back to Hidde’s post, he notes:

My advice would be that whenever tooltips contain more than just plain text, a non-modal dialog would be more appropriate...

So I think the logic goes something like this:

  1. Use title if the content in my popover is just text.
  2. Use the popover attribute if the content is plain text or a menu of options.
  3. Use <dialog> if you need to force the user to make a decision or block all other interactions on the page.

Update: Sara Soueidan replied with a great note that we shouldn’t reach for the title attribute at all and linked to this equally great post about it:

It is primarily displayed as a native tooltip in desktop browsers, and revealed when a user mouse hovers over markup elements the title is set to. Because of this, it has been a universal usability challenge since its inception, as not all users have been consistently able to interact with it.