On browsers, it's at 73% native support on caniuse, and the polyfill is high-quality, by the Chromium team.
As far as looks, it's all fully styleable with CSS so you can make it look however you like.
Historically it's more likely that an unpopular tag will be removed from the HTML spec and removed from browsers than JS will lose compatibility with your code.
For example, a JS flashing text effect from 25 years ago still works. <blink> tags don't.
Most tags that are deprecated in the spec aren't removed (eg marquee) but you shouldn't assume something in the spec will be available forever.
But overall I feel this approach has worked well over the years. With jQuery for example, I only learned enough to get by working in those codebases, but I committed to internalized all of the standardized DOM methods and Array methods and naive XHR workings. Now in these modern times, jQuery still _works_, but whatever I came to know of it is no longer very useful to me, day to day.
And nowadays, even if dialog happened to be deprecated, you could always continue to support it using a custom element if you really needed to (which probably wouldn't be the worst approach even if you were building it from scratch, to be honest).
Alternatively: it works in Blink, but nowhere else.
Meanwhile Safari doesn't support it at all.
The stats on caniuse are skewed by Chromium as usual.
As far as I can tell the rendering is currently hacky (i.e. it doesn't follow the spec but achieves the same visual result) and the implementation is supposed to be tied to the `inert` attribute, which isn't currently implemented in FF. This may not matter to most users but if left as-is would result in cross-browser compatibility issues.
The significant outstanding blocker for FF is re. focus twiddling for better a11y, per recent discussion at whatwg/html#5678, c.f. bugzilla#1660271 & #1701230, and this is hardly boiling-the-oceans stuff.
I'm excited for <dialog>, it's a survivor, and a great simplifier - particularly of dev conversations - and I recommend it (even with interim polyfill) to all and sundry.
https://groups.google.com/g/mozilla.dev.platform/c/gqi4MDQDw...
I would avoid using it.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...
of course, much of the rest is experimental and unimplemented.
Not really, for either menus or non-modal dialogs:
“The details element represents a disclosure widget from which the user can obtain additional information or controls.”
https://html.spec.whatwg.org/multipage/interactive-elements....
Personally I’d rather that the toggle was available as an activation behaviour, and this is an open issue for the HTML standard. https://github.com/whatwg/html/issues/3567
Window.this.modal(<info>Hello world</info>);
Window.this.modal(<alert>Hello world</alert>);
let r = Window.this.modal(<question>Hello world</question>);
will create real modal dialogs (as separate desktop windows).
Full working example of a modal dialog:
The dialog element is fully supported in Chrome/Edge and Firefox nightly, and there's a polyfill[3] for the others.[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...
[3]: https://github.com/GoogleChrome/dialog-polyfill