Implement the dialog element

• Component: DOM
• Status: RESOLVED FIXED

[Dominic Cooney]

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.

[Darin Fisher (:fishd, Google)]

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.

[Theresa O'Connor]

https://bugs.webkit.org/show_bug.cgi?id=84796 tracks the implementation of the new stacking layer that the <dialog> element depends on.

[Radar WebKit Bug Importer]

<rdar://problem/11798655>

[Antti Koivisto]

The current implementation was removed in http://trac.webkit.org/changeset/154835

[Matt Falkenhagen]

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.

[James Craig]

*** Bug 112753 has been marked as a duplicate of this bug. ***

[James Craig]

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.

https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-three

[James Craig]

See also @inert in bug 165279

[Ole Strøm]

https://webkit.org/status/#feature-dialog-element

[Ole Strøm]

(In reply to Ole Strøm from comment #9)
> https://webkit.org/status/#feature-dialog-element

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.

[Steffen Weber]

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?

See https://github.com/GoogleChrome/dialog-polyfill/issues/211

[Simon Fraser (smfr)]

No; the implementation hasn't really started.

[Federico]

I'm wondering why this has not been implemented. It has been almost a decade since it was requested. I could understand the other topics about privacy but this seems to be basic at this point in time. Any plans if it's going to be released during this year or the next one?

(In reply to Federico from comment #13)
> I'm wondering why this has not been implemented. It has been almost a decade
> since it was requested. I could understand the other topics about privacy
> but this seems to be basic at this point in time. Any plans if it's going to
> be released during this year or the next one?
There is currently an unresolved issue in the specification, relating to which element should gain focus. This is why there hasn't been a release yet in Firefox. I don't know if this has slowed Webkit progress, but I imagine a Firefox release would renew interest here. Related links:

  * https://github.com/whatwg/html/issues/1929
  * https://github.com/whatwg/html/pull/4184
  * https://bugzilla.mozilla.org/show_bug.cgi?id=840640

[James Morris]

I have designed many Single Page Applications, and with Edge being on Chromium, the dialog element is THE main thing that makes a small simple application framework not be able to be created. Ie, the dialog polyfill is more code than the entire routing/page display mechanism.  

Surly a question of 'which element gets focused' can be resolved (after 10 years?)

Mozilla are aiming to ship <dialog> support in Firefox 98.

Note that the issue of which element should receive focus has *not* been resolved. However, Firefox compatibility reports (due to lack of <dialog>) suggest it would be better to ship now and potentially amend behaviour later. It's also observed that the accessibility of hand-rolled dialogs is usually worse than <dialog>, so releasing now would be an improvement.