October 7th, 2019
This is me looking at the HTML
<dialog> element for the first time. I’ve been aware of it for a while, but haven’t taken it for a spin yet. It has some pretty cool and compelling features. I can’t decide for you if you should use it in production on your sites, but I’d think it’s starting to be possible.
It’s not just a semantic element, it has APIs and special CSS.
We’ll get to that stuff in a moment, but it’s notable because it makes the browser support stuff significant.
When we first got HTML5 elements like
<article>, it pretty much didn’t matter if the browser supported it or not because nothing was worse-off in those scenarios if you used it. You could make it block-level and it was just like a meaningless div you would have used anyway.
That said, I wouldn’t just use
<dialog> as a “more semantic
<div> replacement.” It’s got too much functionality for that.
Let’s do the browser support thing.
As I write:
- Chrome’s got it (37+), so Edge is about to get it.
- Firefox has the User-Agent (UA) styles in place (69+), but the functionality is behind a
dom.dialog_element.enabledflag. Even with the flag, it doesn’t look like we get the CSS stuff yet.
- No support from Safari.
It’s certainly more compelling to use features with better support than this, but I’d say it’s close and it might just cross the line if you’re the polyfilling type anyway.
On to the juicy stuff.
A dialog is either
open or not.
<dialog> I'm closed. </dialog> <dialog open> I'm open. </dialog>
There is some UA styling to them.
It seems to match in Chrome and Firefox. The UA stylesheet has it centered with auto margins, thick black lines, sized to content.
Like any UA styles, you’ll almost surely override them with your own fancy dialog styles — shadows and typography and whatever else matches your site’s style.
Say you have a reference to the element named
You should probably use this more explicit command though:
That’s what makes the backdrop work (and we’ll get to that soon). I’m not sure I quite grok it, but the the spec talks about a “pending dialog stack” and this API will open the modal pending that stack. Here’s a modal that can open a second stacking modal:
There’s also an HTML-based way close them.
If you put a special kind of form in there, submitting the form will close the modal.
<form method="dialog"> <button>Close</button> </form>
Notice that if you programmatically open the dialog, you get a backdrop cover.
This has always been one of the more finicky things about building your own dialogs. A common UI pattern is to darken the background behind the dialog to focus attention on the dialog.
We get that for free with
::backdrop pseudo-element. Instead of the low-opacity black default, let’s do red with stripes:
Cool bonus: you can use
backdrop-filter to do stuff like blur the background.
It moves focus for you
I don’t know much about this stuff, but I can fire up VoiceOver on my Mac and see the dialog come into focus see that when I trigger the button that opens the modal.
It doesn’t trap focus there, and I hear that’s ideal for modals. We have a clever idea for that utilizing CSS you could explore.
Rob Dodson said: “modals are actually the boss battle at the end of web accessibility.” Kinda nice that the native browser version helps with a lot of that. You even automatically get the Escape key closing functionality, which is great. There’s no click outside to close, though. Perhaps someday pending user feedback.
Ire’s article is a go-to resource for building your own dialogs and a ton of accessibility considerations when using them.