[Discussion] New chance for <dialog>?

[masi]

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

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

outweigh those that don’t. For instance, it’s awesome that Safari now supports the

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.

[chalkygames123]

Sidenote: The good news for such libraries is that the inert attribute is finally coming to the Web: https://twitter.com/jensimmons/status/1512101236560080898

[masi]

Thank you, @KittyGiraudel, for the long and detailed answer. Which makes very clear that I should have explained the reason for opening the ticket. I am sorry for being so terse.

I do believe that we have a need for JavaScript to handle dialogs now and proably for a very long time. I didn't mean to say that <dialog> support in all new major browsers version makes a11y-dialog obsolete.

Mr. O'Hara's article pointed out various shortcomings of Google's polyfill. Sadly there is no further development for this package so everyone has to work around the deficiences.

OTOH you have dropped support for <dialog> in v7 for the good reasons you explain. The new chance I address in the subject is a renewed support for <dialog> in v8. The question is if it is now possible to make a11y-dialog again work as a polyfill and cross-browser consistency library.

Note to @chalkygames123: We must hope that Chrome and Firefox take this as a cue to finish their support for <inert>. They have hidden the feature behind a flag for long enough.

[KittyGiraudel]

OTOH you have dropped support for

in v7 for the good reasons you explain. The new chance I address in the subject is a renewed support for

in v8. The question is if it is now possible to make a11y-dialog again work as a polyfill and cross-browser consistency library.

I think that’s fair. I should look at it again.

[KittyGiraudel]

Will be added to the documentation in v8.