Popover API

[staminade]

I think the Popover API will be really transformative when CSS Anchor Positioning[1] arrives as well. Anchor positioning will let you position elements relative to others on the page. Combined with the Popover API it will let you implement things like custom tooltips and context menus in a declarative way and without any need for libraries like PopperJS [2]

[1] https://developer.chrome.com/blog/tether-elements-to-each-ot... [2] https://popper.js.org/docs/v2/

[unakrav]

I just shipped a new article all about how to use the CSS anchoring API, which is landing in Chromium next week! https://developer.chrome.com/blog/anchor-positioning-api

[threatofrain]

Browser support.

https://caniuse.com/css-anchor-positioning

[pupppet]

Oh the number of hours CSS anchor positioning would’ve saved me over the years.

[ndom91]

This is the critical missing piece. Tried playing with and ship something with the new popover API last week, but missing positioning support in all browsers is really holding this back from more use-cases.

Looks like the last browser (FF) has already shipped anchor positioning in beta, so it won't be long!

[hanniabu]

I'm amazed that in 2024 html/css doesn't have a tooltip attribute like there is for title

[jcutrell]

How is anchor different from relative?

[eknkc]

There is also <dialog> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...) if you want modal dialogs.

[myfonj]

And also <details> if you need expanding/collapsing content, or, with a slight abuse, a "dropdown".

Strange that unlike <dialog open> and <details open>, `<whatever popover>` apparently lacks the the ability to be made declaratively `open` using the attribute. This feels like omission to me. I hope there is some based reasoning behind this decision.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

[threatofrain]

I'd warn that there's a fair bit of work you have to do to get animations and typical modal behavior working up to the level of modern day expectations. It's completely surmountable but also quite non-trivial.

[jacobgorm]

I absolutely see the need for this if implemented in concert with the host OS windowing system, because current popovers must be emulated in a way that does not always work well.

For example, a browser-native <select> today will be able to expand beyond the borders of the hosting browser window, so you can don't have to worry about it getting clipped to the window borders, but a fancy emulated select from toolkit like Quasar will not, ,which limits its placement options. So to do this right on win32 you would need each popover to have its own native HWND and on Cocoa/macOS you would need it in its own NSView.

Does anybody in here know if this is how it is actually implemented in the current browsers, or is it just a paint-over job inside the browser window?

[oefrha]

These popovers are just regular DOM nodes styled with regular CSS.

Giving websites a vector to paint outside the designated viewport (except in extremely limited circumstances like alert(), confirm(), [title], <select>, etc.) makes it a lot easier for them to convincingly emulate browser and OS dialogs. It's a massive security risk, I don't think it's worth the limited upside. Concrete example: a page emulating your password manager extension's unlock widget.

Edit: Note that this is not a theoretical concern. Scammers over the years have created extremely convincing fake UI elements, including fake popup windows complete with the browser chrome. They're even draggable. Not being to paint past the viewport boundary is one of very few, if not the only limitation they couldn't get around.

[Silphendio]

How useful is such a feature in reality? On smaller devices, the web brower almost always covers the whole screen, and even on big monitors, it usually touches at least one corner.

[tootie]

It will also make it semantically easier to detect. I'm thinking about accessibility and crawlability but also in case anyone wants to write some "no popup" plugin.

[rafram]

Firefox, for one, technically supports "popping out" part of a page's content into a separate OS-level window. It exposes that functionality through the XUL <panel> and <menupopup> elements, which are only available to privileged [X]HTML being rendered in the browser's main process. I doubt that any browser developer would want to give ordinary web pages the ability to create borderless OS windows.

[layer8]

I don’t see web apps getting the native windowing system integration you envision anytime soon. The fact that some standard controls behave that way is an OS-specific implementation side effect of them being implemented as OS-native, which they aren’t required to be.

[sseagull]

Kinda funny that browsers have built-in pop-up blockers, but then create APIs like this. Yes I know the difference, but still.

I’m old enough to remember the pop-up and pop-under wars of the late 90s and early 2000s.

I guess we won that particular battle, but the war for our attention is far from over.

[bestest]

I think you're comparing apples with grapples.

A popover is floating element that appears to display a contextual piece of information when required.

What you're mentioning is something completely different.

[jjice]

I get the gist of what you're saying, but I don't think they're really comparable. Popups spam your OS with trash that impairs your ability to use your machine (at worst). Popover dialogs can be shut down by closing your tab and nothing more. We've also had these style of popovers for a while now because they're generally a really handy way of presenting info. Yeah, they can be used in annoying ways, but there are lots of genuine usecases, like a modal.

[gwd]

I'm seeing a lot of this kind of comment, but it's a bit non-sensical. You can implement pop-overs currently using existing <div>'s and such; e.g.:

https://getbootstrap.com/docs/5.3/components/popovers/

All this means is that you can implement popovers without having to include a magic extra library. All blocking an explicit "popover" element would do is cause people to stick with custom libraries.

[1231232131231]

This is not a pop-up. People hate popups because they're intrusive and have their own window. This API replaces div modals and saves time and code for developers.

[gyomu]

The original pop-up implementation (which pop-up blockers aim to prevent) breaks the application content/OS boundary, this does not.

You don’t want that boundary to be broken, because that makes for less usable and less safe systems.

[darby_eight]

It also helps that we now just have spam covering content and slowing our computer down inside the window. Hell, many publications will even get you to pay for the privilege.

[efilife]

I've seen exactly this comment somewhere on HN already. What's going on?

[H1Supreme]

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

Why? This is a legitimate use case for a popover. Especially if you're blurring the background while it's open. Why even offer that feature if a user's click can potentially trigger an action on some blurred out button.

*edit:

Apparently, you can combine the two:

> You can turn a <dialog> element into a popover (<dialog popover> is perfectly valid) if you want to combine popover control with dialog semantics.

Wouldn't <popover modal=true> make more sense here? They're clearly acknowledging a use case.

[eyelidlessness]

Probably, among other things, because <dialog> existed much earlier.

[Waterluvian]

Very cool. So if I understand correctly, this doesn’t really introduce any new capability, it just streamlines the need to have a modal div, mask div, container div, and some uncomfortable positioning CSS? It also adds some pseudo classes to simplify styling. I like it.

[_heimdall]

It also allows for the basic functionality without JS (and without overloading a hidden checkbox). I'm not sure how far that will get you so maybe JS will be needed for a styled and animated popover, but no-JS support with focus handled properly is nice.

I want to say there was also accessibility support built in but now I don't see it in the spec. If it handles announcing the elements to accessibility tools like a screen reader that'll really help too, its pretty easy to forget to do it manually.

[devmor]

The API it introduces also allows the control of popover elements’ visible state in the DOM without any javascript.

That is definitely useful.

[Alifatisk]

Demo https://mdn.github.io/dom-examples/popover-api

[wruza]

And in the nested popovers demo you can't go diagonally from Pizza to Ham, cause nobody in chrome or firefox bothered to implement a delay before a submenu disappears. Decades of UX research lost, almost as expected.

https://mdn.github.io/dom-examples/popover-api/nested-popove...

[nikkwong]

Doesn’t seem to work on safari on iOS although it purportedly should according to the browser support table.

[niek_pas]

This sounds cool, but why does this page not have any images showing what a 'popover' is?

[charlesabarnes]

It has a link to examples that can be found here https://mdn.github.io/dom-examples/popover-api/

[simonw]

That would be useful. They do link to these interactive examples - looks like the default styles for popovers are not very exciting: https://mdn.github.io/dom-examples/popover-api/

[mdev23]

what a time to be alive

[kitallis]

This is great.

Here's a custom implementation with Stimulus using Popper – https://github.com/tramlinehq/tramline/blob/main/app/javascr...

And here's one for <dialog> – https://github.com/tramlinehq/tramline/blob/main/app/javascr...

[silverwind]

I wonder why there is no corresponding `role="popover"` HTML attribute yet.

[megaman821]

The docs warn that there is no role associated with the popover attribute because it could be a menu, tooltip, etc., and you should put the correct role on it. Accessibility-wise it does take care of the item with the popovertarget, so you don't have to put aria-controls and aria-expanded.

[suyash]

I quite like these two examples:

1. Pop up menu like those on Windows/Ubuntu : https://mdn.github.io/dom-examples/popover-api/nested-popove...

2. Android style toast notifications: https://mdn.github.io/dom-examples/popover-api/toast-popover...

[ativzzz]

Was this worth developing?

We already have infinite popover js/css libraries so this doesn't solve any unsolved problem. I suspect this will be like select, where you almost always want some functionality or styling that can't be done natively so you reach for a custom solution or use some existing library.

Maybe if I start a new app this is OK as a stopgap until I need more functionality (which always happens), but in my existing app I'm just using the already existing popover library for consistency

[delichon]

These are popovers:

https://kagi.com/proxy/passover-popovers-6.jpg?c=gBnCtLe1QYl...

No you can't have that word to mean something else, it's sacred. And because you tried you can't have any of my popovers either.

[TrueDuality]

I suspect this isn't going to get major usage. Making it a dedicated API makes these things easier to target by extensions and thus easier to block. There are legitimate usages but almost all of the ones I encounter are marketing call to actions and invasive support chat boxes which are both almost universally hated and would the target of those blocking action.

[ikesau]

in terms of accessibility, i imagine a universal standard for modal state management will be an improvement over the bespoke approach - closing when the user presses escape, focus handling, etc.

but i really wish popover=hint made it into the spec. would have been nice to get a native alternative to tippy.js

[globalise83]

Another extremely useful feature that won’t work for our Safari users with any older than 1 year old iPhones and means for the next five years we have to support both this API and a full-blown polyfill or alternative implementation.

[tijssss]

CSS only tooltips in bootstrap, see https://noojs.pages.dev/components/tooltips.html

[seltzered_]

The popover API feature turned out to be super useful when writing a userscript for extracting data from a website recently.

Allowed a nice way to float a list with content for users to copy.

[jrockway]

It's a shame that browser developers have to implement enough of this API to entice people to use it, only for users to install extensions that simply disable it ;)