Popover API(developer.mozilla.org)
developer.mozilla.org
Popover API
https://developer.mozilla.org/en-US/docs/Web/API/Popover_API
165 comments
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
I love articles with actual running examples, thanks! Now I'm wondering how quickly this will get adopted, it looks very cool!
whats a reasonable expectation for this to get adopted across safari/firefox/edge? 1yr? 3yrs?
Implementation already begun for Firefox:
https://groups.google.com/a/mozilla.org/g/dev-platform/c/4cb...
https://groups.google.com/a/mozilla.org/g/dev-platform/c/4cb...
Fantastically illustrated and interactive article!
I wonder if/how Tailwind will grow to adapt this, as I'm pretty happy with their abstractions now.
The source link at the top of the article leads to a 404.
Browser support.
https://caniuse.com/css-anchor-positioning
https://caniuse.com/css-anchor-positioning
Oh the number of hours CSS anchor positioning would’ve saved me over the years.
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!
Looks like the last browser (FF) has already shipped anchor positioning in beta, so it won't be long!
Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.
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).
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).
Also: Orion uses Webkit on macs. Development is cruising along.
I'm amazed that in 2024 html/css doesn't have a tooltip attribute like there is for title
Does the "title" attribute not work? I tried adding one to the <span> containing your post and it worked. I assume that's non-standard.
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 :))
Edit: Remove extra "if"
Edit: Remove extra "if"
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.
> The title attribute is not accessible
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.
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.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Edit: Formatting
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.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Edit: Formatting
It exists on ios, through some nonsense: https://dev.webonomic.nl/fixing-the-iphone-css-hover-problem...
It takes ages to show up when you’re hovering on something.
The title attribute has poor discoverability since you need to long-tap/hover to see it. Need something that shows instantly.
The title attribute disappears once you move the mouse off the object vs clicking to keep it open or having a delay on it.
You also can't have html in a title attribute.
The title attribute disappears once you move the mouse off the object vs clicking to keep it open or having a delay on it.
You also can't have html in a title attribute.
[deleted]
How is anchor different from relative?
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/
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.
They explain in the first couple paragraphs of the first link provided.
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.
There is also <dialog> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...) if you want modal dialogs.
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...
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...
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.
(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.
Yes, it was clarified in a Twitter thread [1].
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.
[1] https://twitter.com/myfonj/status/1789238215771037836
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.
[1] https://twitter.com/myfonj/status/1789238215771037836
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:
<style> dialog::backdrop { backdrop-filter: blur(4px); }
/* IS-OPEN STATE / dialog[open] { translate: 0 0; }
/ EXIT STATE / dialog { transition: translate 0.2s ease-out, overlay 0.2s ease-out, display 0.2s ease-out allow-discrete; translate: 384px 0; }
/ 0. BEFORE-OPEN STATE */ @starting-style { dialog[open] { translate: 384px 0; } } </style> ```
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.
[1] https://developer.chrome.com/blog/what-is-the-top-layer [2] https://github.com/whatwg/html/issues/8339 [3] https://developer.chrome.com/blog/entry-exit-animations [4] https://codepen.io/kevinpowell/pen/QWaBeGm
- 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:
<style> dialog::backdrop { backdrop-filter: blur(4px); }
/* IS-OPEN STATE / dialog[open] { translate: 0 0; }
/ EXIT STATE / dialog { transition: translate 0.2s ease-out, overlay 0.2s ease-out, display 0.2s ease-out allow-discrete; translate: 384px 0; }
/ 0. BEFORE-OPEN STATE */ @starting-style { dialog[open] { translate: 384px 0; } } </style> ```
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.
[1] https://developer.chrome.com/blog/what-is-the-top-layer [2] https://github.com/whatwg/html/issues/8339 [3] https://developer.chrome.com/blog/entry-exit-animations [4] https://codepen.io/kevinpowell/pen/QWaBeGm
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.
This doesn’t sound right at all.
Ubuntu itself doesn’t have an ESR package, only https://packages.ubuntu.com/focal/firefox which is at 125.
The Mozilla PPA does have an ESR package, but per https://launchpad.net/~mozillateam/+archive/ubuntu/ppa?field... it’s at 115.
<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.
Ubuntu itself doesn’t have an ESR package, only https://packages.ubuntu.com/focal/firefox which is at 125.
The Mozilla PPA does have an ESR package, but per https://launchpad.net/~mozillateam/+archive/ubuntu/ppa?field... it’s at 115.
<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.
As mentioned in the first few paragraphs of TFA.
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?
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.
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.
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.
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.
The assumption is that webpages are safe to browse.
Installable programs grant a degree of trust over your system.
If webpages are unsafe, or have native capabilities, the World Wide Web becomes less useful, as the act of clicking a link is heavy thing.
Installable programs grant a degree of trust over your system.
If webpages are unsafe, or have native capabilities, the World Wide Web becomes less useful, as the act of clicking a link is heavy thing.
Nothing at all.
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.
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.
[deleted]
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.
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.
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.
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.
A popover is floating element that appears to display a contextual piece of information when required.
What you're mentioning is something completely different.
> 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.
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.
I don't think this is often called "pop-up", mostly I see either popover or tooltip.
Maybe by developers. But the public certainly calls them pop-ups
https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...
https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...
[deleted]
I tend to use "apples to aardvarks" but now I'm not sure whether I like mine or yours better.
Shall have to alternate them for a bit and call it A/G testing.
Shall have to alternate them for a bit and call it A/G testing.
And surely this new API will not be abused. Right?
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.
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.
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.
[deleted]
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.
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.
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.
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.
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.
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'm strongly in favor of the popover API existing, but it'll be interesting to see how it shifts handling page behaviors.
Obnoxious modals with ads would still download the content dynamically with JS so the NoScript would still do the job.
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...
Both things are true. Popups are more disruptive because they remain even after the page that spawned them is closed and often obscure their origin.
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.
The big difference is that there are very few valid use cases for popups, but many useful ones for popovers.
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.
Which people still hate because its mostly marketing trash that gets in the way of whatever they were trying to do on the underlying page.
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.
You don’t want that boundary to be broken, because that makes for less usable and less safe systems.
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.
I've seen exactly this comment somewhere on HN already. What's going on?
Perhaps they typed it into the wrong tab, deleted it and reposted it here?
Doesn't seem to be a re-peat according to https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Doesn't seem to be a re-peat according to https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Deja vu?
I did start to type this as a response elsewhere, but never submitted it. And there’s nothing in my comment history.
So my theory is “great minds think alike” :)
I did start to type this as a response elsewhere, but never submitted it. And there’s nothing in my comment history.
So my theory is “great minds think alike” :)
> 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.
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.
Probably, among other things, because <dialog> existed much earlier.
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.
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.
The API it introduces also allows the control of popover elements’ visible state in the DOM without any javascript.
That is definitely useful.
That is definitely useful.
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...
https://mdn.github.io/dom-examples/popover-api/nested-popove...
Doesn’t seem to work on safari on iOS although it purportedly should according to the browser support table.
This sounds cool, but why does this page not have any images showing what a 'popover' is?
It has a link to examples that can be found here https://mdn.github.io/dom-examples/popover-api/
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/
Default styles only make things harder to customize. If we didn't have so many useless/ugly default styles, we wouldn't need reset.css/normalize.css
How would you prefer it? I think the default styles (on chrome) are just enough, looks consistent with the rest of the default HTML styles.
what a time to be alive
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...
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...
I wonder why there is no corresponding `role="popover"` HTML attribute yet.
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.
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...
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...
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
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
Every single app having to import the same popper library, for over a decade, indicates there's sufficient need for native support.
I've also been a proponent of a combobox becoming native (for ex: a select box of Countries where you can filter by typing) https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#:~:text=C.... and ideally multi-select for ex a tag selector.
I've also been a proponent of a combobox becoming native (for ex: a select box of Countries where you can filter by typing) https://www.w3.org/WAI/ARIA/apg/patterns/combobox/#:~:text=C.... and ideally multi-select for ex a tag selector.
That's the point. Why make the life easier for websites that display pop-ups. Pop-ups are pure evil.
What does that have to do with popovers, though?
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.
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.
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.
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.
That is quite a curious URL. The querystring is identifying the file, but it looks as if it’s hosted at https://kagi.com/proxy/passover-popovers-6.jpg
That's the image proxy from the kagi search engine.
It's very likely built this way so
a) if you download it the image has the correct file name
b) the source URL is encoded in the query string and you can't abuse Kagi as a 'file host' by just plugging in any URL
It's very likely built this way so
a) if you download it the image has the correct file name
b) the source URL is encoded in the query string and you can't abuse Kagi as a 'file host' by just plugging in any URL
Cliff House at Land's End in San Francisco had legendary popovers - too bad they closed down
I once asked a question about popovers, one guy replied he googled what they were and got hungry.
Never heard of them. Any good? Something you make yourself or by ready? Eaten hot or cold?
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.
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.
Glad I'm not entirely alone in having this thought.
[ponders offering to swap for half his sandwich]
[realises he made himself a bacon and sausage sandwich]
... never mind.
[googles in shame]
... ooooh, it's a cousin of a Yorkshire Pudding, I knew it looked tasty!
[realises he made himself a bacon and sausage sandwich]
... never mind.
[googles in shame]
... ooooh, it's a cousin of a Yorkshire Pudding, I knew it looked tasty!
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.
What about selecting an image to view?
What about cookie consents?
Also universally hated and widely blocked.
Very much a anti-pattern. The entire concept of these is malicious compliance against the GDPR and not something that the GDPR requires.
The ePrivacy directive does require them, though. (Of course, not in the malicious-compliance form we see today.)
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
but i really wish popover=hint made it into the spec. would have been nice to get a native alternative to tippy.js
Standards work is progressing on this, hopefully this year.
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.
https://developer.apple.com/support/app-store/
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.
https://developer.apple.com/support/app-store/
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.
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.
> though not one you can launch
Try the app "Activity launcher" on your phone some time. Lets you open any Activity (android class that apps are composed of) on your device.
Try the app "Activity launcher" on your phone some time. Lets you open any Activity (android class that apps are composed of) on your device.
Is it recommended to update iOS with old phones? Not recommended by Apple, actually recommended as in it won't slow your phone to a crawl.
Ignorance, or just anti-Apple lies? This is pure misinformation and hurts web development.
Practical experience having to build workarounds to support Safari users whose browser versions don't support modern web APIs.
CSS only tooltips in bootstrap, see https://noojs.pages.dev/components/tooltips.html
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.
Allowed a nice way to float a list with content for users to copy.
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 ;)
Already here submitted: https://news.ycombinator.com/item?id=40043029
As someone who does some (but not a lot of) web development, I guess the only thing I care about is: can I turn this off with uBlock Origin?
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.
God damn I love their docs
Ah, prompt()/alert()
> The Popover API provides developers with a standard, consistent, flexible mechanism for displaying popover content on top of other page content.
Paywall 2.0?
Paywall 2.0?
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)
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 lack of this API wasn’t stopping anyone from implementing a paywall.
> The lack of this API wasn’t stopping anyone from implementing a paywall.
Obviously -- that's inferred by the 2.0.
Obviously -- that's inferred by the 2.0.
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.
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.
This seems to be modelled after Sciter's popups that existed 10 or so years.
anchorElement.popup(elementToPopup, options) - https://docs.sciter.com/docs/DOM/Element/#popup
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
anchorElement.popup(elementToPopup, options) - https://docs.sciter.com/docs/DOM/Element/#popup
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
button.onclick = function() {
button.popup(<select type="list">
<option>A</option>
<option>B</option>
<option>C</option>
</select>)
}
[1] https://developer.chrome.com/blog/tether-elements-to-each-ot... [2] https://popper.js.org/docs/v2/