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