Bug 84635 - Implement the dialog element
Summary: Implement the dialog element
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Tim Nguyen (:ntim)
URL: https://html.spec.whatwg.org/multipag...
Keywords: InRadar, WebExposed
: 112753 (view as bug list)
Depends on: 84796 110952 227534 227537 227801 227907 90521 90670 90931 90934 95946 103719 112085 113273 205542 205543 226169 226172 226175 227493 227523 227566 227800 227802 227872 227915 227986
Blocks: 159753
  Show dependency treegraph
 
Reported: 2012-04-23 14:37 PDT by Dominic Cooney
Modified: 2021-07-15 03:24 PDT (History)
43 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Cooney 2012-04-23 14:37:12 PDT
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.
Comment 1 Darin Fisher (:fishd, Google) 2012-04-23 21:20:05 PDT
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.
Comment 2 Theresa O'Connor 2012-04-24 16:21:18 PDT
https://bugs.webkit.org/show_bug.cgi?id=84796 tracks the implementation of the new stacking layer that the <dialog> element depends on.
Comment 3 Radar WebKit Bug Importer 2012-07-03 10:24:46 PDT
<rdar://problem/11798655>
Comment 4 Antti Koivisto 2013-08-29 13:21:15 PDT
The current implementation was removed in http://trac.webkit.org/changeset/154835
Comment 5 Matt Falkenhagen 2016-01-31 18:12:57 PST
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.
Comment 6 James Craig 2016-03-24 11:56:46 PDT
*** Bug 112753 has been marked as a duplicate of this bug. ***
Comment 7 James Craig 2016-03-24 12:00:48 PDT
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
Comment 8 James Craig 2016-12-08 18:59:41 PST
See also @inert in bug 165279
Comment 10 Ole Strøm 2020-12-08 01:44:07 PST
(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.
Comment 11 Steffen Weber 2020-12-16 05:25:53 PST
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
Comment 12 Simon Fraser (smfr) 2020-12-16 09:41:55 PST
No; the implementation hasn't really started.
Comment 13 Federico 2021-05-11 14:22:22 PDT
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?
Comment 14 dmh 2021-06-28 09:28:05 PDT
(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