Popover API
developer.mozilla.org
developer.mozilla.org
[1] https://developer.chrome.com/blog/tether-elements-to-each-ot... [2] https://popper.js.org/docs/v2/
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/
Edit: Remove extra "if"
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.
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
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.
Looks like the last browser (FF) has already shipped anchor positioning in beta, so it won't be long!
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).
https://groups.google.com/a/mozilla.org/g/dev-platform/c/4cb...
- 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
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...
(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.
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.
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?
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.
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.
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.
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.
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.
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.
A popover is floating element that appears to display a contextual piece of information when required.
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.
https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...
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.
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.
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 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.
Shall have to alternate them for a bit and call it A/G testing.
Doesn't seem to be a re-peat according to https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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” :)
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'm strongly in favor of the popover API existing, but it'll be interesting to see how it shifts handling page behaviors.
You don’t want that boundary to be broken, because that makes for less usable and less safe systems.
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.
That is definitely useful.
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.
https://mdn.github.io/dom-examples/popover-api/nested-popove...
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...
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...
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
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.
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.
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.
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.
[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!
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
but i really wish popover=hint made it into the spec. would have been nice to get a native alternative to tippy.js
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.
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.
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.
Allowed a nice way to float a list with content for users to copy.
Paywall 2.0?
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)
Obviously -- that's inferred by the 2.0.
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.
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>)
}