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

121–130 of 166 posts

Re: Popover API

#121

Post by sseagull »

The_Colonel wrote: post #110
alt227 wrote: post #33

Earlier quoted context omitted.

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

I don't think this is often called "pop-up", mostly I see either popover or tooltip.

Maybe by developers. But the public certainly calls them pop-ups

https://www.google.com/search?hl=en&q=%22newsletter%20pop%2D...

Re: Popover API

#124

Post by ndom91 »

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…

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!

Re: Popover API

#125

Post by marginalia_nu »

The_Colonel wrote: post #114
marginalia_nu wrote: post #41

Earlier quoted context omitted.

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.

The big difference is that there are very few valid use cases for popups, but many useful ones for popovers.

Keep in mind this was a time when virtually all state was kept serverside. Basically anything you could do with a popover you could do with a popup, and there were definitely benign uses of them.

Re: Popover API

#126

Post by uses »

codelikeawolf wrote: post #96
jimbobthrowawy wrote: post #90

Earlier quoted context omitted.

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"

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

Re: Popover API

#127

Post by coldpie »

maccard wrote: post #50
1231232131231 wrote: post #24

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.

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.

If you haven't already, go enable the Annoyances and Cookie banner filter lists in your uBlock Origin installation. It doesn't get all of them, of course, but it does get a lot. For the remainder, the Kill Sticky bookmark is pretty good about knocking them out: https://www.smokingonabike.com/2024/01/20/take-back-your-web...

Re: Popover API

#128

Post by monsieurbanana »

afavour wrote: post #57
globalise83 wrote: post #39

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.

Two year old iPhones are absolutely able to upgrade to iOS 17 and receive this feature, all the way back to iPhone 8. 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.

Is it recommended to update iOS with old phones? Not recommended by Apple, actually recommended as in it won't slow your phone to a crawl.

Re: Popover API

#130

Post by paulddraper »

threatofrain wrote: post #46
oefrha wrote: post #14

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

The assumption is that webpages are safe to browse.

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.

Post reply on HN