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.
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.
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.
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.
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)
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.
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.
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.
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 :(
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).
> 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.
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!
> 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!
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.
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
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.
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.
54 comments
[ 2.6 ms ] story [ 132 ms ] threadStrong 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.
https://github.com/WebKit/standards-positions/issues/74
Hmm. I wish some other ones got as warm of a reception as this one.
Progressive enhancement should be the default, not rejecting APIs because they're not available everywhere. Especially in this case because there's a polyfill...
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.
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.
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)
Of course everyone is free to cheer for it. I, for one, refrain from celebrating.
Also, this change will make it easier to make a popover-blocker than it was before.
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.
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.
Anyway, this is Chrome-only for now, so unless Safari implements this, it can't become mainstream.
But there are very few situations where you'd need a modal.
And right there you lose the elderly crowd who will never learn how to use tabs and barely understand the back button.
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.
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
Everything old is new again :( arghhh popups
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!
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
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.