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

101–110 of 166 posts

Re: Popover API

#101

Post by Zecc »

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"

Why "can't" (won't) screen readers pick up the title attribute?

Re: Popover API

#102

Post by dmix »

ativzzz wrote: post #100

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…

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.

Re: Popover API

#103

Post by betagammaxyz »

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.

There's not much to stop what you describe, other than the trust you place in a native app when you install it. Super common experience to have to give superuser access once during an installation process, and most bets are off regarding security once you do that. That's part of the added friction involved in running a native app; you have to trust it more.

Only other alternative I can think of would be an Apple App Store-style review process where the task of proving trustworthiness gets shifted onto the developer rather than the user. But it's still based around human trust rather than a platform constraint.

Re: Popover API

#104

Post by woodrowbarlow »

ativzzz wrote: post #100

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…

for anyone who views third-party dependencies as a liability (license changes, leftpad drama, etc.), the ability to easily ditch them in favor of native implementations is a win.

Re: Popover API

#106

Post by dawnerd »

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"

Not just screen readers. Basically no support for anyone not using a mouse to navigate. Also really annoying when people put link text in a title on links.

Re: Popover API

#107

Post by shaan7 »

Ok something is really wrong with my brain. I read this as "Poopover API", and it keeps on happening throughout the comments -.-

Re: Popover API

#108

Post by jwells89 »

nerdponx wrote: post #45
bestest wrote: post #18

Earlier 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 might be, but at least the offending site can be taken care of by closing a single tab.

The part that sucked about old style popups is that they leaked into and on occasion would hijack (in the case of popup chains) your OS’ windowing system and at best make a mess of things or at worst turn your computer unusable.

Re: Popover API

#109

Post by The_Colonel »

ativzzz wrote: post #100

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…

Yeah, just like e. g. flexbox doesn't solve any unsolved problems, you can do any layout with JavaScript.

The problem with dropdown is that it has an immense variety of use cases which is difficult to generify. Still, I'm happy we have a basic native Select element, it's competely fine for 8/10 use cases, and okish for 1/10.

OTOH, I believe that a popover is a much more generic feature and most you'd like to customize is styling.

Re: Popover API

#110

Post by The_Colonel »

alt227 wrote: post #33
bestest wrote: post #18

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

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