My notes on this:<p>- <dialog>.showModal() is an indirect API to `top-layer`.<p>- `top-layer` is kind of like a sibling to the root <html>, elements can be placed into the top-layer <i>from any position in the existing DOM</i> (it is like they have two positions). This allows co-locating your <dialog> next to the relevant elements in the tree.<p>- There is only one `top-layer` but it can have many children. Last opened === current element on top.<p>- Z-index has no effect in the top-layer. No need to compete for a higher z-index.<p>- ::backdrop is a pseudo element that you can style behind the <dialog>. It is always below the last <dialog> opened.<p>- Not supported in Safari <= 15.3
Wish I could use this, but Safari only started supporting this as of 15.4, which was released less than a year ago. I'll likely have to wait another 2-3 years until our site stops seeing these older Safari browsers.<p>EDIT: looks like Firefox released support around the same time, but my company's Firefox users seem to be all be ok more recent versions.
> The native HTML <dialog> element should be used in creating modal dialogs as it provides usability and accessibility features that must be replicated if using other elements for a similar purpose. Use the appropriate .showModal() or .show() method to render dialogs. If creating a custom dialog implementation, ensure all expected default behaviors are supported and proper labeling recommendations are followed.<p>Any bets how long it will take JS frameworks to catch up to default behavior?<p>Many websites still do not manage to properly make the back and forward button work, even after years.<p>I am glad, that more semantic elements made it into HTML, reducing the amount of stuff needed to make simple things. I only wish, that we used the standard more.
Supported on all major browsers and 93% of total users according to caniuse.com<p><a href="https://caniuse.com/?search=dialog" rel="nofollow">https://caniuse.com/?search=dialog</a>
It doesn't seem to prevent scrolling?<p><a href="https://jsfiddle.net/46nha7v3/" rel="nofollow">https://jsfiddle.net/46nha7v3/</a><p>I enjoy native elements when they are there. You can do really nice interactive trees with the <details> element for example:<p><a href="https://twitter.com/marekgibney/status/1593950777739218947" rel="nofollow">https://twitter.com/marekgibney/status/1593950777739218947</a><p>But I am not sure if it is a good idea to bake more and more of them into the browsers. Couldn't well made JavaScript modules provide the same functionality without making browsers more and more complex?
At least this should theoretically make it easier to block those horrible popup modals, if they're all grouped under one element:<p><pre><code> dialog {display:none}</code></pre>
I came across this element few weeks ago.<p>Before this,I used to use a div with stuff, and javascript to show hide that div when required. E.g. Spanner icon in this page, lower left corner: <a href="https://spa.bydav.in/tsDMV/tsVerif.html" rel="nofollow">https://spa.bydav.in/tsDMV/tsVerif.html</a><p>Now, recently I used this dialog element with javascript & buttons to show hide div. E.g like Settings button at <a href="https://spa.bydav.in/weather/" rel="nofollow">https://spa.bydav.in/weather/</a><p>I like that it comes on top, stays in center, no checkbook & css stuff.
The interesting thing about <dialog> is that it uses the "top layer" which always appears above everything else on the page regardless of z-index. So you can delete hacks like z-index:2147483647.
Masters of convolution.<p>> the returnValue property gets set to the value of the button that was used to save the form's state.<p>So a more complex form will have to shove all its data into a single attribute for retrieval? Notice the example provide returns the favorite animal as “cancel” if you hit cancel.
I replaced all uses of 3rd party dialogs with this native version in all my client projects (who's browsers support this feature) last year. Works well and that extra code is now gone.<p>More advanced <select> elements are what I'd like to see support for next.
Anyone seeing that the topic tag for comments on this thread is truncated after the "The", presumably something to do with the < character?
Makes me wonder, the more JS functionality creeps into html and css, the less we need JS. I'm curious if that's an acknowledged future that these consortiums and working groups are headed toward, even if unspoken.
Tried to make it useful here: <a href="https://radogado.github.io/n-modal/" rel="nofollow">https://radogado.github.io/n-modal/</a>
> <i>It is important to provide a mechanism to close a dialog within the dialog element. For instance, the Esc key does not close non-modal dialogs by default, nor can one assume that a user will even have access to a physical keyboard (e.g., someone using a touch screen device without access to a keyboard).</i><p>Well this is annoying as a user. Not being able to click away or use escape to close it feels like built in pop up that can’t be ignored.
Maybe someone can explain the reason why the imperative and the declarative way of controlling the open state works differently.<p>I run into the modal/no modal thing just a day ago.