Popover API

https://developer.chrome.com/blog/introducing-popover-api/

by soheilpro • 3 years ago

87 52 3 years ago

developer.chrome.com

rektide• 3 years ago

The main awesome thing about stuff like this is that user-extensions can (where applicable - I'm looking at you scumbag chrome android) modify the user experience at the user's pleasure. Send the toast messages to some other side channel, or just hide them altogether.

Strong personal bias but modals always felt like a huge sign of weakness, a narrowing of complex situations to make UI design easier/simpler, but not necessarily better.

sergiomattei• 3 years ago

This is great, but unsupported anywhere but Chromium-based browsers at the moment.

abhayhegde• 3 years ago

Other browsers will follow the suit soon.

benatkin2• 3 years ago

https://github.com/mozilla/standards-positions/issues/698

https://github.com/WebKit/standards-positions/issues/74

Hmm. I wish some other ones got as warm of a reception as this one.

onion2k• 3 years ago

So use it to progressively enhance your app when it's viewed in Chromium, and provide functionality a different way for other browsers.

Progressive enhancement should be the default, not rejecting APIs because they're not available everywhere. Especially in this case because there's a polyfill...

sam_goody• 3 years ago

And, considering that many devs only support for Chrome, will mean that it will be implemented without any second thoughts.

Users will see a page that only works in Chrome, and a few more users and devs will move over.

And the Chrome team will become ever more entrenched in their belief that they control the web, and Google will faithfully look to use that power against us.

Google already tried to move the web to their servers with AMP. They are not on your side.

modeless• 3 years ago

Hopefully this will solve the very common issue where people naively listen to mouseup on the background to dismiss the popup, with the result that selecting text with the mouse dismisses the popup if the pointer happens to stray slightly outside the popup before you release the mouse button.

ddalex• 3 years ago

Now, we only have to invent ways to center the popover....

shmde• 3 years ago

There goes the frontend interview question to Design a Modal Popup.

Zecc• 3 years ago

On the contrary. It will give a new data point on how up-to-date the interviewee's knowledge is.

ivolimmen• 3 years ago

So we get easier ads... yey. On the other hands this will be easier to be blocked

v3ss0n• 3 years ago

That's nonsense, have you read the specs? It's nothing more than current just/css popovers. I think you are mistaken with popups.

prokopton2• 3 years ago

Nobody reads passed titles.

dx034• 3 years ago

If any click outside of the ad dismisses it, it'd be much more user friendly than many current implementations. I guess advertisers will stay with current solutions where you have to find a tiny x to close the ad.

not_your_vase2• 3 years ago

Ahh, we have invented native popups again, about a decade and a half after we managed to successfully block them.

In about 3 years we will finally have a popover-blocker that eliminates these annoying "subscribe to my newsletter" and "5% off now" popovers.

And in 10 years we invent a "slideontop" element, which will have the same functionality.

charcircuit• 3 years ago

This is not the same thing as a popup window. Clicking on the main window did not close a popup window, but rather backgrounded it. This popup implementation is no different than what is already possible with css.

pcthrowaway• 3 years ago

This popup implementation is no different than what is already possible with css

There are certainly differences. Accessibility, tab functionality, semantics. But most importantly, browsers can sensibly position these to flow away from the edge of the screen when the containing element is at the edge of the viewport (previously with CSS you'd have to choose a direction, and would need Javascript to position anything based on the element's place in the viewport)

jy14898• 3 years ago

Isn't that a feature? If everyone uses the same API, it makes it easier to block in general

not_your_vase2• 3 years ago

Yes, with the current ManifestV2 and ManifestV3 - for now. There is a reason why Google is pushing hard to define what the internet is, and what is possible to do on it and what not.

Of course everyone is free to cheer for it. I, for one, refrain from celebrating.

kristiandupont• 3 years ago

There are popovers everywhere already, so it's not like this is going to introduce them, it will just make it more likely that they close they way you expect them to, handle focus correctly etc. I think it's great.

Also, this change will make it easier to make a popover-blocker than it was before.

varenc2• 3 years ago

It doesn't take 3 years. Here you go:

   *##[popover]

That uBlock Origin rule will block any HTML element with a 'popover' attribute. I just tested and can confirm that popovers never display for me now. This is a simple type of ad–block rule that will even work in manifest v3.

If blocking popovers is really what you want, you should be celebrating that they're now clearly indicated in the markup. Instead of figuring out the particular incantation to block a popover on some site, you can block them easily per-site or everywhere. If anything, intrusive popover usage will be limited because of how easy they are to block. Ad displayers will end up avoiding them.

Of course, I don't think you actually want to do this. There's many uses of popovers that aren't intrusive. But I'm really struggling to see how this makes anything worse.

that_guy_iain• 3 years ago

Of course, I don't think you actually want to do this. There's many uses of popovers that aren't intrusive. But I'm really struggling to see how this makes anything worse.

This is probably the sort of person who disabled JavaScript and went around telling people their site doesn't work without JavaScript instead of enabling JavaScript.

lopis• 3 years ago

This could replace all the libraries used to create modals, and all their complexity. But I'm afraid people will start blocking all `popover` elements and spoil this for everyone.

Anyway, this is Chrome-only for now, so unless Safari implements this, it can't become mainstream.

supriyo-biswas• 3 years ago

Safari has it in its Technology Preview as indicated by the eye icon in the web.dev article.

s4i• 3 years ago

A polyfill for orher browsers seems to be available: https://github.com/oddbird/popover-polyfill

stephane-klein• 3 years ago

https://youdontneedamodalwindow.dev/

troupo3• 3 years ago

You do, due to accessibility in certain contexts. E.g., filling a form should really be a modal (e.g. on a site or in apps catering to the elderly) so that the focus doesn't stray away.

But there are very few situations where you'd need a modal.

oneeyedpigeon• 3 years ago

In that situation, what is the benefit of a modal versus a full page that only contains the form?

chownie• 3 years ago

Modals are almost always atrocious experiences for screen reader users though, so not sure if that tradeup is worth it.

tpmx• 3 years ago

Don't open the details in a modal window. Have it be a separate page.

And right there you lose the elderly crowd who will never learn how to use tabs and barely understand the back button.

orangepanda• 3 years ago

I like how they included video examples, for those whose browsers dont support the api. I liked more how on safari all the videos are just white.

LeoNatan25• 3 years ago

I saw a video on Safari Mobile. Could be blocked on your end by a content blocker.

The_Colonel• 3 years ago

The web platform keeps growing which is concerning ... but things like this make a lot of sense. Popovers are omnipresent, but you typically need a library (or buggy custom code).

ximm• 3 years ago

A dialog element opened with dialog.showModal (a modal dialog), is an experience which requires explicit user interaction to close the modal. A popover supports light-dismiss. A modal dialog does not. A modal dialog makes the rest of the page inert. A popover does not.

If those are the only differences I do not understand why they need to invent an entirely new API for this. Why not add options to dialog.showModal? In my experience, light-dismiss also makes sense for many dialogs.

I really want to have great, accessible dialogs and popups. But after dialogs were added to chrome in 2014 it took 8 years until there were also available in firefox and safari. I do not want to have to wait for that long again.

troupo3• 3 years ago

But after dialogs were added to chrome in 2014 it took 8 years until there were also available in firefox and safari. I do not want to have to wait for that long again.

The problems with dialog were so numerous that no one wanted them as specified. At one point Chrome suggested that `dialog` spec should be removed. [0]

But then a curious thing happened: browsers decided to remove alert/confirm/prompt with zero replacement for their functionality [1]. Once again, Chrome was the first to announce this, with an insanely short deadline.

After an outcry (and an outrage) this was rolled back, and literally within months `dialog` with no changes and all the issues intact and unsolved landed in all major browsers.

[0] https://github.com/whatwg/html/pull/4184#issuecomment-440405...

[1] https://dev.to/richharris/stay-alert-d

al_be_back• 3 years ago

I like it! When are you releasing the Popover-Blocker API?

Everything old is new again :( arghhh popups

benatkin2• 3 years ago

If all the browsers are on the same page, I support it. I checked standards positions and I see they are, at least for now. I hope it stays that way and helps simplify web development!

samwillis• 3 years ago

Promotion to the top layer. Popovers will appear on a separate layer above the rest of the page, so you don’t have to futz around with z-index.

Having recently been working with popup menus inside a virtualised infinity scroll, with an impossible z-index stack, that makes my heart sing. Potentially no more somewhat ugly Vue Teleport or React Portal hacks!

0xy• 3 years ago

What about popovers on top of popovers? We now need a popover z-index :)

qingcharles• 3 years ago

It's popovers all the way down!

janosdebugs2• 3 years ago

If what you are looking for, is a JS-less popover experience, you can already do much of this with a label, a checkbox, and the next sibling selector. The label can act as the clickable interface to drive the checkbox, while the checkbox can drive the display of the popover.

rpastuszak• 3 years ago

How does this work from the accessibility pov?

janosdebugs2• 3 years ago

Almost perfectly, the only issue I found was having to set the aria-modal with JS for the popover if I remember correctly. Tested it with screen readers on Android and iOS. (We built the website on my profile page with this, if I remember correctly, I'm not at my computer right now.)

extra88• 3 years ago

The checkbox's checked/unchecked state is not a good way to convey a popover state.

Some other limitations of the checkbox hack compared to this new `popover` attribute:

* doesn't support closing a popover by pressing the ESC key, something interfaces that can overlap other content should support * doesn't support closing by clicking anywhere outside the popover

hit8run• 3 years ago

Finally. HTML needs more UI primitives.

solarkraft• 3 years ago

Whenever I see something about browser APIs from Google I think "this is probably not a standard".

varenc2• 3 years ago

It is in fact part of the latest standard: https://html.spec.whatwg.org/multipage/popover.html#the-popo...

Safari and Edge preview builds are supporting popover as well. Mozilla has indicated they’re “positive” on it. Still might be a long time before it’s generally usable but it is in the standard.

dthedavid• 3 years ago

Cool. I'm building something like this on the side. It's called bannerbox.io. The difference is that it requires no code, has a WYSIWYG editor and works everywhere.

butz• 3 years ago

Bootstrap will be able to drop its last external dependency now.

Popover API

Related Stories