[Discussion] New chance for <dialog>?

Scott O’Hara writes:

It’s now March of 2022, and Webkit 15.4 has shipped the <dialog> element, as well as Firefox 98. All major browsers now support the <dialog> element, and that’s really exciting.

Please note that you should definitely start (continue) tinkering with the <dialog> element. There are still ongoing discussions about some aspects of the <dialog> element, but things are looking promising.

[KittyGiraudel]

Hello and thank you for asking! 👋

Things look promising and hopefully we’ll reach a stage where the <dialog> element is widely supported and consistent enough that we can put a11y-dialog to sleep. But this is not quite the case just yet.

And there are still reasons to use a11y-dialog (or a similar library):

• Not wanting to deal with browsers inconsistencies. It would be a bad reason to use a JavaScript library if <dialog> worked without JavaScript, which it doesn’t. So if you want a dialog that looks the way you expect everywhere, then a lib like a11y-dialog remains the way to go.
• Having to support old browsers without the <dialog> element. I guess a polyfill might be better in a case like that, but also maybe not. Depends on the polyfill I suppose. Might as well use the same lib for everything.
• Needing alertdialog support. There is no plan for the <dialog> element to support role="alertdialog" as far as I’m aware, so if that’s a need, then a11y-dialog remains a good option.
• Building more complex interactions relying on events. The native <dialog> element doesn’t come with an event API, so you cannot react to it being open or closed.
• Using a framework-specific wrapper around it, like React or Vue.js. It’s going to be easier to integrate with a11y-dialog than the native one in my opinion.

For what it’s worth, the very next paragraph after the one you’ve quoted states:

For the time being, I would still advocate people use robust custom dialogs, such as a11y-dialog, or at the very least ensure their <dialog> elements can fallback to custom dialogs in the event people are not using the most up-to-date browsers. That is until usage stats for browsers that support <dialog> outweigh those that don’t. For instance, it’s awesome that Safari now supports the <dialog> element, but since Safari releases are so tightly coupled with OS updates, not everyone is going to get this update nearly as quickly as those using Firefox, Chrome and Edge.

So we’re not quite there yet, and we might never be. That being said, once things are clean and shiny all around, I’ll happily update the a11y-dialog documentation to explain when it’s worth using over the native <dialog> element.

[KittyGiraudel]

Will be added to the documentation in v8.