Skip to main content

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

Howdy—Robin Rendle here. I started this side project back in May because I wanted a dedicated place to learn-out-loud about all the exciting things that’s happening in the world of CSS.

And so many exciting things are happening!

Right now we’re living through a golden age: what was once a language that was easy to make fun of has 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:

Tagged with

Javascript free navigation

Thanks to Andy Bell’s ever-so-good newsletter, The Index, I found myself ooo-ing and aaa-ing at Michelle Barker’s excellent post from back in May about creating a JavaScript-free menu with the latest bells and whistles like anchor-positioning and the Popover API:

Anchor positioning in CSS enables us to position an element relative to an anchor element anywhere on the page. Prior to this we could only position an element relative to its closest positioned ancestor, which sometimes meant doing some HTML and CSS gymnastics or, more often than not, resorting to Javascript for positioning elements like tooltips or nested submenus.

There’s a lot of good examples in that post that are worth checking out but one thing that stuck out to me was the <menu> HTML element which we can use like this for a series of interactive actions:

</menu> have I never used this before!?

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.