Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] New chance for <dialog>? #330

Closed
masi opened this issue Apr 3, 2022 · 5 comments
Closed

[Discussion] New chance for <dialog>? #330

masi opened this issue Apr 3, 2022 · 5 comments

Comments

@masi
Copy link

masi commented Apr 3, 2022

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
Copy link
Owner

KittyGiraudel commented Apr 4, 2022

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
Copy link
Contributor

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
Copy link
Author

masi commented Apr 8, 2022

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
Copy link
Owner

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 KittyGiraudel changed the title new chance for <dialog> now that Safari and FF support it? [Discussion] New chance for <dialog>? Jul 5, 2022
@KittyGiraudel
Copy link
Owner

Will be added to the documentation in v8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants