Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popover API

developer.mozilla.org

Post reply on HN
Print view View original

41–50 of 166 posts

Re: Popover API

#41

Post by marginalia_nu »

1231232131231 wrote: post #24
sseagull wrote: post #13

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.

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.

Re: Popover API

#42

Post by TrueDuality »

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.

Re: Popover API

#43

Post by staminade »

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]

[1] https://developer.chrome.com/blog/tether-elements-to-each-ot... [2] https://popper.js.org/docs/v2/

Re: Popover API

#44

Post by megaman821 »

silverwind wrote: post #28

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.

Re: Popover API

#45

Post by nerdponx »

bestest wrote: post #18
sseagull wrote: post #13

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 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?

Re: Popover API

#46

Post by threatofrain »

oefrha wrote: post #14
jacobgorm wrote: post #9

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 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…

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.

Re: Popover API

#47

Post by myfonj »

eknkc wrote: post #11

There is also ( https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... ) if you want modal dialogs.

And also if you need expanding/collapsing content, or, with a slight abuse, a "dropdown".

Strange that unlike and , `` 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...

Re: Popover API

#48

Post by Thorrez »

TrueDuality wrote: post #42

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?

Re: Popover API

#49

Post by jcutrell »

staminade wrote: post #43

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] [1] https://developer.chrome.com/blog/tether-elements-to-eac…

How is anchor different from relative?

Re: Popover API

#50

Post by maccard »

1231232131231 wrote: post #24
sseagull wrote: post #13

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.

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.
Post reply on HN