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 ;)
Popover API
131–140 of 166 posts
Re: Popover API
#132I 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 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…
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 and 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.
Re: Popover API
#133Earlier quoted context omitted.
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], , 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…
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.
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.
Re: Popover API
#134Earlier quoted context omitted.
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.
And surely this new API will not be abused. Right?
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.
Re: Popover API
#135This 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 – https://github.com/tramlinehq/tramline/blob/main/app/javascr...
Re: Popover API
#136I 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-eac…
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
Re: Popover API
#137Was 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…
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.
That's the point. Why make the life easier for websites that display pop-ups. Pop-ups are pure evil.
Re: Popover API
#138I 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-eac…
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!
Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.
Re: Popover API
#139I 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-eac…
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!
Re: Popover API
#140Earlier quoted context omitted.
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"
> 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.
It exists on ios, through some nonsense: https://dev.webonomic.nl/fixing-the-iphone-css-hover-problem...