This is part of the HTML5 spec: <http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element>
This manages a stack of dialogs and should let pages show “page modal” UI without resorting to modal dialogs (alert, confirm, prompt) and without the difficulty of managing pop-up windows or in-page divs.
Implementation note: We should make sure that windowed plugins cannot sit on top of a rendered dialog. Windowed plugins by default cover the rendered page as they are implemented using a native window (e.g., HWND). To give the illusion of the page being on top, it is necessary to cut-out part of the native window (e.g., using SetWindowRgn). We already have machinery in WebKit for this as you can position an IFRAME above an EMBED (using CSS Z-index) to cause the IFRAME to occlude the EMBED. See the getPluginOcclusions function defined in IFrameShimSupport.cpp. That file would probably need to be renamed.
https://bugs.webkit.org/show_bug.cgi?id=84796 tracks the implementation of the new stacking layer that the <dialog> element depends on.
The current implementation was removed in http://trac.webkit.org/changeset/154835
FWIW this element was implemented in Chromium <https://www.chromestatus.com/feature/5770237022568448>, but I'm not actively working on it for WebKit. So, I'll unassign myself.
*** Bug 112753 has been marked as a duplicate of this bug. ***
Focus keyboard behavior seems reasonably specified, though Chrome's implementation does not yet support it. We'd need the "Focus Fix-up" rule for FKA and AX.
See also @inert in bug 165279
(In reply to Ole Strøm from comment #9)
Woops. Still figuring Bugzilla out.
What I meant to say, was that I've sneakily added Jon Davis to the CC list, in hopes that he might see this, and that he might give us a status on this.
Is this still the main entry/bug for https://webkit.org/status/#feature-dialog-element? Is it actually still "Under Consideration"?
I'd really love to see this added, especially since it seems Firefox's implementation is nearing public release.
Then it would be just Safari holding us back: https://caniuse.com/dialog
Which I find strange, seeing it would be a huge win for accessibility.
And Apple have a really good track record for accessibility. I'm in AWE each time I see some of the clips in the promos, showcasing that anyone can do advanced stuff, like editing a video!
Stuff like that inspires me to push accessibility hard on the web stuff I create.
Which is why you're reading this. This dialog element would be a huge win for accessibility, and the need for dialogues is prevalent on the web, especially modern web applications.
I'd love some inputs and thoughts on all of this.
Especially if I just should go ahead and use https://github.com/GoogleChrome/dialog-polyfill until it's no longer needed, or if there are some better alternatives.
The experimental feature "Dialog Element" in Safari 14 doesn't fire "close" events when closing a dialog. Should I file a separate issue for this?
No; the implementation hasn't really started.