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]
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!
Safari and Mobile Safari are common and are neither Firefox nor Chrome derivatives.
Uncommon and neither Firefox nor Chrome Derivatives: Netsurf, Dillo, Ladybird each have their own engines. A few browsers also use a Gecko fork called Goanna. (Pale Moon comes to mind first, but there are at least a couple others that use the same engine.) Then there's Konqueror. It's not common, but can either use old KHTML or WebKit (Safari's engine).
The title attribute is not accessible, so its use is generally discouraged as an accessible label because screen readers can't pick it up (it's fine to use if you combine it with aria-label). Also, you can only show text in a title attribute, so the Popover API would allow you to add rich content to a tooltip (for better or worse :))
They do pick up the "title" attribute sometimes and apply it as a label. But it's not really the same as being able to keyboard navigate to the browser-generated tooltip.
Not just screen readers. Basically no support for anyone not using a mouse to navigate. Also really annoying when people put link text in a title on links.
That's incorrect. There's nothing inherently inaccessible about the title attribute.
Voiceover, for example, reads the content of title attributes.
There are a bunch of reasons why title is pretty useless (the main one being it does nothing on every touch screen interface, where the concept of hover doesn't exist). But accessibility is not one of them.
> That's incorrect. There's nothing inherently inaccessible about the title attribute.
I think we might be splitting hairs here. There are accessibility concerns with the title attribute. MDN describes why the title attribute is problematic from an accessibility perspective [1] and provides a list of links with additional details. That MDN page also indicates that the title attribute is problematic for:
- People using touch-only devices
- People navigating with keyboards
- People navigating with assistive technology such as screen readers or magnifiers
- People experiencing fine motor control impairment
- People with cognitive concerns
That's a non-trivial amount of web users. So is it technically accessible? Yes. But if you want to deliver an accessible experience to everyone, and the title attribute is going to cause issues, I personally would define that as not being accessible.
The article I linked goes into the details, but basically a relative approach constrains your markup: The positioned thing must be a child of the relatively positioned anchor or a wrapper element, and you often cannot sensibly position it without using JS to check the location of the anchor. E.g. a popover menu for a button must check if the button is close to an edge of the viewport and position the menu element appropriately. Anchor positioning will do this automatically.
Also, if support for multiple anchors is included, then it opens up some very interesting capabilities to do things like draw arbitrary diagram connectors between elements: https://kizu.dev/anchor-positioning-experiments/
I've been eagerly awaiting anchor positioning, but using it for diagram connectors had not occurred to me yet! That would solve so many problems that I currently have (or plan) to use D3 for.
position: relative adds a fixed offset to the position the element would have been placed in normally, but position: anchor can be used to place an element near any arbitrary element, regardless of its place in the DOM hierarchy.
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.
Maybe because 'dialog' says "don't do that" but everybody did anyway?
(also possibly because the "insert into top layer" is sufficiently odd a thing to trigger that the designers felt representing it as an attribute was a worse idea than for dialog)
... though I'd really like some sort of explanation as to how to choose between "non-modal <dialog>" and popover because the one thing I am very confident of here is that I don't know enough to answer that question myself.
As I understand the line of thought around modals there it is: If it has to be declaratively opened modal on each page visit, blocking other content, it should better be an extra page anyway. (The fact it is made possible imperatively with JS is considered "necessary evil" as I understand it.) The same presumably applies for popover; default-open popover could probably make sense in application that uses JS anyway, not a static document. (?)
Nuances of distinction between popover and non-modal dialog I have to explore.
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.
I don't agree as I have converted all the modals/dialog in my web app to <dialog> and boy it has been a breeze. A few killer features:
- Goodbye z-index, since the last opened dialog always get's promoted to the top in #top-layer [1]
- Free focus handling, it doesn't trap focus inside dialog but that's kinda opinionated anyway [2]
- styling and animation is EASY with `@starting-style` and `allow-discrete` and can even use view-transitions [3]
Here's a basic sliding in drawer with blurred background I have in svelte:
Some of the features are not yet available in firefox and safari but they are coming soon and they have minimal workarounds available now [4] for animating `display: none` etc. So, I'd say it's time we retire that quirky UI library's dialog.
As someone pointed out, it's indeed harder to animate but it's fully accessible, supports escape key to close, has a built-in backdrop and has built-in focus trap.
Safari took a while to support it but now it's available everywhere. I think it's better than using a <div> tag.
Apparently it's unsupported in the Firefox ESR version in Ubuntu 20.04, which still receives support from Canonical until 2025. I found that out because someone reported that my site didn't work.
<dialog> has been supported since Firefox 98, meaning ESR 91 was the last release lacking it, and it reached end of support over a year and a half ago.
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?
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.
Let's say there's a native app that can also do pop ups. What's to stop the native app from basically stealing the likeness of your password manager? In other words, as web apps seek to become like native apps, they may also accrue the risks which are characteristic of that space.
Native apps have to be installed. You don't want to give every power they have to random websites (say, that phishing domain at the top of a Google SERP), not for a very good reason. "My custom dropdown can't draw past the boundary of the viewport" isn't a very good reason.
Giving this capability to arbitrary web apps is definitely a bad idea, but conceivably it could be made available to installed PWAs in the same way things like the Window Controls API are: https://developer.mozilla.org/en-US/docs/Web/API/Window_Cont...
PWAs can contain dynamic ads elements, which will try to abuse that. If it was normal for desktop apps to run some remote view+script sandboxes, this problem would extend there too. On one hand, PWAs are apps, on the other, they enable the spirit of downloadable web content much more easily.
There's not much to stop what you describe, other than the trust you place in a native app when you install it. Super common experience to have to give superuser access once during an installation process, and most bets are off regarding security once you do that. That's part of the added friction involved in running a native app; you have to trust it more.
Only other alternative I can think of would be an Apple App Store-style review process where the task of proving trustworthiness gets shifted onto the developer rather than the user. But it's still based around human trust rather than a platform constraint.
I see two parts to this. One is the role of user choice in deterring system damage from bad apps, and the other is the role of app stores in shielding the user from having to make this choice to begin with.
On the matter of websites, if the decision rests on individual choice, then individuals certainly have a choice to visit (and thus trust) a particular domain name and cert. That users need merely type in a name, and that there's a giant company helping you search for these apps, simply means that web apps are easy to find and install (and native apps are only slightly harder to install).
Then there's the role of the app stores, which I imagine practically deals with the supermajority of garbage, spams and scams out there. We could also have orgs whose sole job is to maintain lists of credibility, if that's what people want. Then a web user could download a browser extension or use a browser that subscribed to these lists by default. In some ways that's what ad blockers are, except ad blockers are even more precise and there's nothing quite like it in the native world.
Related note: this is also why iPad and Android tablet apps don't have real popovers or floating toolbars either. Mobile treats the window boundary as sacred.
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.
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.
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.
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.
> What you're mentioning is something completely different.
I think that is because the term 'Pop-up' has changed. It used to mean the opening of a new browser window, typically smaller than the host window and floating somewhere on top.
Now it means a modal form within the same window and dom.
At this point in the web's development the better question is: will this allow our abusers to do things that weren't possible before or in ways that are less blockable than before?
I think the answer is pretty clearly no to both questions, but it will allow us to simplify a lot of our code that was designed to make actually-useful popovers.
It might be, but at least the offending site can be taken care of by closing a single tab.
The part that sucked about old style popups is that they leaked into and on occasion would hijack (in the case of popup chains) your OS’ windowing system and at best make a mess of things or at worst turn your computer unusable.
It seems like the only context in which it could be abused would be if you have JS disabled but this still works? (Because of course you can do this with JS).
As CSS becomes more powerful it seems like being able to disable these powerful features, while still retaining the “document styling” features, will be important.
it doesn't allow developers to do anything they can't already do.
it does make those elements easier for adblockers to remove though, by implementing the functionality in a standard way that constrains all the related logic into one easily removable element.
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.
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.
I generally agree with you, but one factor is the ability to filter out scripts using browser plugins. For example, if a page has 3rd-party scripts that trigger obnoxious modals, I can use NoScript to prevent those scripts from executing. If it doesn't require scripts to open the modals, would it shift the burden to adblockers, and start another competition in which the site and the adblocker are trying to get around the other?
I'm strongly in favor of the popover API existing, but it'll be interesting to see how it shifts handling page behaviors.
I still don't think there's any significant difference. You can create popover elements without JavaScript, but you can also create divs with a high z-index without JavaScript. You can toggle popover visibility via CSS or click without JavaScript, but you can also do that with divs and a checkbox.
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.
No, people hate pop ups because they steal focus and draw attention away from the content they’re interested in. Whether it’s a pop up or a popover, a prompt asking me to sign up to your newsletter is not something I want.
If you haven't already, go enable the Annoyances and Cookie banner filter lists in your uBlock Origin installation. It doesn't get all of them, of course, but it does get a lot. For the remainder, the Kill Sticky bookmark is pretty good about knocking them out: https://www.smokingonabike.com/2024/01/20/take-back-your-web...
They're basically the same. Browsers started blocking popups because they were almost always misused. Pop-overs took their place because they're somewhat less trivially blockable.
Keep in mind this was a time when virtually all state was kept serverside. Basically anything you could do with a popover you could do with a popup, and there were definitely benign uses of them.
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.
> 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.
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.
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.
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.
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.
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
for anyone who views third-party dependencies as a liability (license changes, leftpad drama, etc.), the ability to easily ditch them in favor of native implementations is a win.
Yeah, just like e. g. flexbox doesn't solve any unsolved problems, you can do any layout with JavaScript.
The problem with dropdown is that it has an immense variety of use cases which is difficult to generify. Still, I'm happy we have a basic native Select element, it's competely fine for 8/10 use cases, and okish for 1/10.
OTOH, I believe that a popover is a much more generic feature and most you'd like to customize is styling.
They are quite delicious. Home made, eaten hot, with butter in our home. It's a Jewish Passover tradition that I find to be odd, because it is supposed to be part of an ascetic ritual in which we forego "leavened" bread and so instead eat matzo and popovers. But instead of being any kind of sacrifice it is a great treat, especially in a household that doesn't otherwise serve fresh baked bread.
It's like telling a kid they've been naughty so they can't have the old cookies, they have to eat fresh baked cookies instead.
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.
You don't think sites will use tooltips and dropdown menus. You are probably confusing these for popups which open new browser windows, popover happen within the webpage when a piece of UI needs to be drawn over existing content.
When I first read about this API a while back, I thought the same thing. But it's perfect for adding complex controls on top of inputs when you have limited real estate (e.g. clicking on an input with a font name and showing a font picker popover with a preview of the font). This is obviously possible today without this API, but I like that they added something semantic. I regularly have to wade through the ARIA docs to figure out which role/aria- attributes to use.
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
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.
All iPhones going all the way back to 2018 can upgrade to iOS 17 right now.
66% of all active iPhones are already on iOS 17, 23% are on iOS 16, and only 11% use anything older. People upgrade iOS fairly quickly and it’s uncommon to support anything more than the two most recent major versions. So it’s more like one year, not five.
Two year old iPhones are absolutely able to upgrade to iOS 17 and receive this feature, all the way back to iPhone 8.
That said, I do wish Apple had their browser set up like Google does with a complete upgrade possible via the App Store. It feels unnecessary to completely tie it to the OS version.
I don't know how iOS works but if it was an app would other browsers be able to use Safari's rendering engine? There is also the lower functionality JS engine that Apple forces those browsers to use (if I'm not mistaken.)
The way it works on Android is that the system web view is an "app" (though not one you can launch) that updates via the Play Store. Any app using webviews automatically gets the upgraded experience whenever that app gets upgraded.
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 ;)
That’s like asking if you can turn off <form>s. Not sure why you’d want to. It’s a perfectly reasonable component that doesn’t need to be abused for ads.
I use <dialog> a lot when building websites. I don't run any ads nor promotional content so if that element was blocked it would break lots of features.
Seems like you could, since it has an attribute and a pseudo class to select on.
document.querySelectorAll("[popover]:popover-open")
should select all visible popovers. AFAIK uBlock uses regular CSS selectors.
I've used it to implement windows for drilling deeper into rarely used settings in a web-based HMI.
It makes for very simple design compared to using JavaScript, and provides easy layering in DOM for it (including if you want to just delete the popover :D)
The pessimist inside me worries about whether this could be used to lure people into revealing their credentials; granted, there are thousands of ways to do this easily, but I'm still cautiously optimistic on this topic.
So I think this API would just allow a bad actor to get your credentials in a way that adheres to accessibility guidelines. It doesn't enable them to do anything they couldn't do before programmatically.
Saw an interesting case of this type of attack in the CounterStrike community earlier this week.
Someone setup a fake tournament website that asked the user to login with their Steam account. Then it launched what looked like a new browser window with the Steam login page, but was actually just a popover that had been elaborately styled, with window decorations and all.
In Sciter popup element is always associated with its anchor element and appears relative to it.
CSS was expanded to support popups: :popup state flag/selector is "on" the popup element and :owns-popup is "on" on popup anchor element when the popup is shown. Also several CSS properties: popup-position, popup-anchor-reference-point, popup-reference-point, popup-animation.
Sciter has built-in JSX and so element.popup() accepts JSX that creates popup DOM element on demand, for example this
[1] https://developer.chrome.com/blog/tether-elements-to-each-ot... [2] https://popper.js.org/docs/v2/