111–120 of 166 posts
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...
Earlier quoted context omitted.
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 '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.
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…
Earlier quoted context omitted.
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 '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.
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…
Earlier quoted context omitted.
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.
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.
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.
What about cookie consents?
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(
A
B
C
)
}
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.
You don’t want that boundary to be broken, because that makes for less usable and less safe systems.
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.
Earlier 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"
Why "can't" (won't) screen readers pick up the title attribute?