Popover API is Here

The Popover API has support across browsers now, and apparently the new way to say that is “landed in Baseline”, albeit as “newly available” rather than “widely available”, which may be an important distinction for you.

A popover is very much like a <dialog> in that you don’t have to worry about where it exists in the DOM. When it’s open, it will be “on top”. That alone is a sick feature. I dislike having to put modals as children of the <body> just so they don’t have other elements inescapable stacking contexts to worry about.

So then how is it different than a <dialog>? Popups are not “modal”. The web-world definition of modal is that it forces a user to deal with it (the rest of the page cannot receive focus, it is inert). Popups just… pop… up. The user is free to do anything else while a popup is open. Dialogs, not so much.

Robin showed off how extremely very easy it is to use:

<button popovertarget="mypopover">Toggle the popover</button>

<div id="mypopover" popover>Popover content</div>Code language: HTML, XML (xml)

The fact that that’s possible in HTML alone is awfully nice. But of course you can style it with CSS if you like. Plus you get freebies like the fact that they ESC key closes it. Taking it a bit further, here’s an only slightly more fleshed out example using other cool freebies like popovertargetaction="hide":

(p.s. I dig the trick of getting a white ❌ with the filter property as shown above. Golf clap.)

Robin goes on to say that the logic for using it is something like this:

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

I only disagree on the first one. I think title is pretty useless and I only tend to include one if some accessibility tool warns me to add one, like on an <iframe>. The title attribute does nothing on mobile/touch devices or screen readers. You can’t control anything about it, like how it looks, where it goes, or how long it takes to show up if it does at all. If we get more control over it (which, who knows, we might) then I’d be happy to take another look, but it seems likely it’ll still be a “only use if it’s a just text” situation.

I’m certainly a fan of this API existing, but I do think it’s very hampered right now without the Anchor Position API being nearly as well supported. Massive use cases like tooltips or flyout menus aren’t really possible without it. Una has written about this as well. And good news, it can also be HTML powered.

<button id="menu-toggle" popovertarget="menu-items">
  Open Menu

<ul id="menu-items" popover anchor="menu-toggle">
  <li class="item">...</li>
  <li class="item">...</li>
</ul>Code language: HTML, XML (xml)

Note the anchor attribute there connecting the two elements. So cool. And again, you can take finer grained control with CSS if you’d like. “Open right next to this other element” is clutch. Heads up though, the anchor attribute is not ready yet.

Taking it futher, here’s another idea from Una that uses an anchor element as a central position and then moves individual items in a circle around it.

I’ll tell ya, Una is ready with all this! Particularly with the Anchor Positioning API, she’s got a bunch of demos and a little helper website to make sure you can declare the positioning CSS you intend:

I now will await patiently the Anchor Positioning API to drop everwhere. Alas, Popover was part of interop 2024 where Anchor was not.

Wanna learn CSS from a course?

Frontend Masters logo

FYI, we have a full CSS learning path with multiple courses depending on how you want to approach it.

2 responses to “Popover API is Here”

  1. Avatar eugene andruszczenko says:

    With animation and ::backdrop

Leave a Reply

Your email address will not be published. Required fields are marked *