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

141–150 of 166 posts

Re: Popover API

#141

Post by wruza »

staminade wrote: post #70
oefrha wrote: post #66

Earlier quoted context omitted.

Native apps have to be installed. You don't want to give every power they have to random websites (say, that phishing domain at the top of a Google SERP), not for a very good reason. "My custom dropdown can't draw past the boundary of the viewport" isn't a very good reason.

Giving this capability to arbitrary web apps is definitely a bad idea, but conceivably it could be made available to installed PWAs in the same way things like the Window Controls API are: https://developer.mozilla.org/en-US/docs/Web/API/Window_Cont...

PWAs can contain dynamic ads elements, which will try to abuse that. If it was normal for desktop apps to run some remote view+script sandboxes, this problem would extend there too. On one hand, PWAs are apps, on the other, they enable the spirit of downloadable web content much more easily.

Re: Popover API

#142

Post by wruza »

Alifatisk wrote: post #105

Demo https://mdn.github.io/dom-examples/popover-api

And in the nested popovers demo you can't go diagonally from Pizza to Ham, cause nobody in chrome or firefox bothered to implement a delay before a submenu disappears. Decades of UX research lost, almost as expected.

https://mdn.github.io/dom-examples/popover-api/nested-popove...

Re: Popover API

#143

Post by hoistbypetard »

Fatnino wrote: post #138
ndom91 wrote: post #124

Earlier quoted context omitted.

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!

Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.

Safari and Mobile Safari are common and are neither Firefox nor Chrome derivatives.

Uncommon and neither Firefox nor Chrome Derivatives: Netsurf, Dillo, Ladybird each have their own engines. A few browsers also use a Gecko fork called Goanna. (Pale Moon comes to mind first, but there are at least a couple others that use the same engine.) Then there's Konqueror. It's not common, but can either use old KHTML or WebKit (Safari's engine).

Re: Popover API

#144

Post by codelikeawolf »

uses wrote: post #126
codelikeawolf wrote: post #96

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"

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

> That's incorrect. There's nothing inherently inaccessible about the title attribute.

I think we might be splitting hairs here. There are accessibility concerns with the title attribute. MDN describes why the title attribute is problematic from an accessibility perspective [1] and provides a list of links with additional details. That MDN page also indicates that the title attribute is problematic for:

- People using touch-only devices

- People navigating with keyboards

- People navigating with assistive technology such as screen readers or magnifiers

- People experiencing fine motor control impairment

- People with cognitive concerns

That's a non-trivial amount of web users. So is it technically accessible? Yes. But if you want to deliver an accessible experience to everyone, and the title attribute is going to cause issues, I personally would define that as not being accessible.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Edit: Formatting

Re: Popover API

#145

Post by filleduchaos »

cynicalsecurity wrote: post #137
dmix wrote: post #102

Earlier quoted context omitted.

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.

That's the point. Why make the life easier for websites that display pop-ups. Pop-ups are pure evil.

What does that have to do with popovers, though?

Re: Popover API

#146

Post by throawayonthe »

Fatnino wrote: post #138
ndom91 wrote: post #124

Earlier quoted context omitted.

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!

Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.

[dead]

Re: Popover API

#147

Post by wizzwizz4 »

TrueDuality wrote: post #115
Thorrez wrote: post #48

Earlier quoted context omitted.

What about cookie consents?

Very much a anti-pattern. The entire concept of these is malicious compliance against the GDPR and not something that the GDPR requires.

The ePrivacy directive does require them, though. (Of course, not in the malicious-compliance form we see today.)

Re: Popover API

#148

Post by swyx »

mardifoufs wrote: post #139
unakrav wrote: post #136

Earlier quoted context omitted.

I just shipped a new article all about how to use the CSS anchoring API, which is landing in Chromium next week! https://developer.chrome.com/blog/anchor-positioning-api

I love articles with actual running examples, thanks! Now I'm wondering how quickly this will get adopted, it looks very cool!

whats a reasonable expectation for this to get adopted across safari/firefox/edge? 1yr? 3yrs?

Re: Popover API

#149

Post by b1tr0tt »

ikesau wrote: post #32

in terms of accessibility, i imagine a universal standard for modal state management will be an improvement over the bespoke approach - closing when the user presses escape, focus handling, etc. but i really wish popover=hint made it into the spec. would have been nice to get a native alternative to tippy.js

Standards work is progressing on this, hopefully this year.

Re: Popover API

#150

Post by oidar »

hoistbypetard wrote: post #143
Fatnino wrote: post #138

Earlier quoted context omitted.

Aren't there only 2 browsers? There is Firefox and there are all the Chrome derivatives.

Safari and Mobile Safari are common and are neither Firefox nor Chrome derivatives. Uncommon and neither Firefox nor Chrome Derivatives: Netsurf, Dillo, Ladybird each have their own engines. A few browsers also use a Gecko fork called Goanna. (Pale Moon comes to mind first, but there are at least a couple others that use the same engine.) Then there's Konqueror. It's not common, but can either use old KHTML or WebKit…

Also: Orion uses Webkit on macs. Development is cruising along.
Post reply on HN