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

91–100 of 166 posts

Re: Popover API

#91

Post by gwd »

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'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.

Re: Popover API

#92

Post by codelikeawolf »

algasami wrote: post #40

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.

Re: Popover API

#93

Post by megaman821 »

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.

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.

Re: Popover API

#94

Post by nojs »

delichon wrote: post #53

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.

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

Re: Popover API

#95

Post by jimbobthrowawy »

afavour wrote: post #81
pmontra wrote: post #75

Earlier quoted context omitted.

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.

Re: Popover API

#96

Post by codelikeawolf »

jimbobthrowawy wrote: post #90
hanniabu wrote: post #85

Earlier quoted context omitted.

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

Re: Popover API

#97

Post by pupppet »

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…

Oh the number of hours CSS anchor positioning would’ve saved me over the years.

Re: Popover API

#98

Post by tshaddox »

jimbobthrowawy wrote: post #90
hanniabu wrote: post #85

Earlier quoted context omitted.

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 containing your post and it worked. I assume that's non-standard.

It takes ages to show up when you’re hovering on something.

Re: Popover API

#99

Post by ysavir »

gwd wrote: post #91
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'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 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.

Re: Popover API

#100

Post by ativzzz »

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

Post reply on HN