Popover API | Hacker News Reader

Popover API

developer.chrome.com

87 pointssoheilpro52 comments

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.

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.

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

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

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.

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.

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.

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

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.

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

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.

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

https://youdontneedamodalwindow.dev/

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.

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

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

No idea how screen readers work for native modals, but on the web I'm not surprised: it's very hard to make a proper modal (with proper focus, keyboard trapping etc.) on the web :(

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.

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.

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

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

> 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

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

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

Nobody reads passed titles.

Why did the titles pass?

I’m sorry. If I could fix the typo, I would.

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.

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

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

It's popovers all the way down!

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

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

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

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.

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

Finally. HTML needs more UI primitives.

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.

How does this work from the accessibility pov?

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

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

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!

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.

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

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.

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

Everything old is new again :( arghhh popups

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

Other browsers will follow the suit soon.

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.

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

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.

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

Reply on news.ycombinator.com