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: Nobody
URL: https://html.spec.whatwg.org/multipag...
Keywords: InRadar, WebExposed
: 112753 (view as bug list)
Depends on: 84796 95946 103719 90521 90670 90931 90934 110952 112085 113273 205542 205543
Blocks: 159753
  Show dependency treegraph
 
Reported: 2012-04-23 14:37 PDT by Dominic Cooney
Modified: 2020-12-16 09:41 PST (History)
41 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.