9 ms·

Popover API

87 points by soheilpro 3y ago

al_be_back 3y ago
I like it! When are you releasing the Popover-Blocker API? Everything old is new again :( arghhh popups
s4i 3y ago
A polyfill for orher browsers seems to be available: https://github.com/oddbird/popover-polyfill https://github.com/oddbird/popover-polyfill
rektide 3y 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 3y ago
This is great, but unsupported anywhere but Chromium-based browsers at the moment.
- abhayhegde 3y ago
  Other browsers will follow the suit soon.
  - benatkin 3y ago
    https://github.com/mozilla/standards-positions/issues/698 https://github.com/mozilla/standards-positions/issues/698 https://github.com/WebKit/standards-positions/issues/74 https://github.com/WebKit/standards-positions/issues/74 Hmm. I wish some other ones got as warm of a reception as this one.
- onion2k 3y 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 3y 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 3y 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 3y ago
  Now, we only have to invent ways to center the popover....
shmde 3y ago
There goes the frontend interview question to Design a Modal Popup.
- Zecc 3y ago
  On the contrary. It will give a new data point on how up-to-date the interviewee's knowledge is.
ivolimmen 3y ago
So we get easier ads... yey. On the other hands this will be easier to be blocked
- v3ss0n 3y 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.
  - prokopton 3y ago
    Nobody reads passed titles.
    - Robbsen 3y ago
      Why did the titles pass?
      - prokopton 3y ago
        I’m sorry. If I could fix the typo, I would.
- dx034 3y 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_vase 3y 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 3y 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 3y 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 3y ago
  Isn't that a feature? If everyone uses the same API, it makes it easier to block in general
  - not_your_vase 3y 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 3y 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.
stephane-klein 3y ago
https://youdontneedamodalwindow.dev/ https://youdontneedamodalwindow.dev/
- troupo 3y 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 3y ago
    In that situation, what is the benefit of a modal versus a full page that only contains the form?
    - troupo 3y ago
      [dead]
  - chownie 3y ago
    Modals are almost always atrocious experiences for screen reader users though, so not sure if that tradeup is worth it.
    - troupo 3y ago
      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 :(
- tpmx 3y 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 3y 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 3y ago
  I saw a video on Safari Mobile. Could be blocked on your end by a content blocker.
The_Colonel 3y 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).
deleted 3y ago
[deleted]
ximm 3y 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.
- troupo 3y 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-440405059 https://github.com/whatwg/html/pull/4184#issuecomment-440405... [1] https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d
benatkin 3y 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 3y 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 3y ago
  What about popovers on top of popovers? We now need a popover z-index :)
  - qingcharles 3y ago
    It's popovers all the way down!
janosdebugs 3y 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 3y ago
  How does this work from the accessibility pov?
  - janosdebugs 3y 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 3y 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 3y ago
Finally. HTML needs more UI primitives.
solarkraft 3y ago
Whenever I see something about browser APIs from Google I think "this is probably not a standard".
- varenc 3y ago
  It is in fact part of the latest standard: https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute 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 3y 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 3y ago
Bootstrap will be able to drop its last external dependency now.

87 points by soheilpro 3y ago

I like it! When are you releasing the Popover-Blocker API? Everything old is new again :( arghhh popups

s4i 3y ago

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

rektide 3y 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 3y ago

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

abhayhegde 3y ago
Other browsers will follow the suit soon.
- benatkin 3y ago
  https://github.com/mozilla/standards-positions/issues/698 https://github.com/mozilla/standards-positions/issues/698 https://github.com/WebKit/standards-positions/issues/74 https://github.com/WebKit/standards-positions/issues/74 Hmm. I wish some other ones got as warm of a reception as this one.
onion2k 3y 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 3y 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 3y 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 3y ago
Now, we only have to invent ways to center the popover....

shmde 3y ago

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

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

ivolimmen 3y ago

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

v3ss0n 3y 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.
- prokopton 3y ago
  Nobody reads passed titles.
  - Robbsen 3y ago
    Why did the titles pass?
    - prokopton 3y ago
      I’m sorry. If I could fix the typo, I would.
dx034 3y 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_vase 3y 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 3y 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 3y 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 3y ago
Isn't that a feature? If everyone uses the same API, it makes it easier to block in general
- not_your_vase 3y 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 3y 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.

stephane-klein 3y ago

https://youdontneedamodalwindow.dev/ https://youdontneedamodalwindow.dev/

troupo 3y 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 3y ago
  In that situation, what is the benefit of a modal versus a full page that only contains the form?
  - troupo 3y ago
    [dead]
- chownie 3y ago
  Modals are almost always atrocious experiences for screen reader users though, so not sure if that tradeup is worth it.
  - troupo 3y ago
    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 :(
tpmx 3y 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 3y 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 3y ago
I saw a video on Safari Mobile. Could be blocked on your end by a content blocker.

The_Colonel 3y 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).

deleted 3y ago

[deleted]

ximm 3y 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.

troupo 3y 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-440405059 https://github.com/whatwg/html/pull/4184#issuecomment-440405... [1] https://dev.to/richharris/stay-alert-d https://dev.to/richharris/stay-alert-d

benatkin 3y 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 3y 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 3y ago
What about popovers on top of popovers? We now need a popover z-index :)
- qingcharles 3y ago
  It's popovers all the way down!

janosdebugs 3y 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 3y ago
How does this work from the accessibility pov?
- janosdebugs 3y 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 3y 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 3y ago

Finally. HTML needs more UI primitives.

solarkraft 3y ago

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

varenc 3y ago
It is in fact part of the latest standard: https://html.spec.whatwg.org/multipage/popover.html#the-popover-attribute 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 3y 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 3y ago

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