[meta] Implement the HTML5 dialog element
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
People
(Reporter: dmh, Unassigned)
References
(Depends on 2 open bugs, Blocks 4 open bugs)
Details
(5 keywords, Whiteboard: [devRel:P2])
Attachments
(1 file, 1 obsolete file)
4.86 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130201065344 Steps to reproduce: Please add support for the dialog element, which makes it easier to develop stackable dialog boxes and pop-up UI components within an HTML document. http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#the-dialog-element (Work to support <dialog> and its associated API within WebKit began in 2012, but is not yet complete.)
Comment 1•11 years ago
|
||
Sounds like something humph would be interested in :)
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 2•11 years ago
|
||
Comment 3•11 years ago
|
||
There is an implementation of this in the latest builds of Chrome Canary (32.0.1653.0) and a demo and polyfill here: http://demo.agektmr.com/dialog/
Updated•11 years ago
|
Comment 4•10 years ago
|
||
Hi all. I've been working on implementing <dialog> in Chrome behind a flag and am thinking of exposing it by default soon. I'm curious about whether Mozilla folks feel positively about this feature and the current spec, or if anyone feels shipping is a bad idea? Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element Demo: http://demo.agektmr.com/dialog/
Updated•10 years ago
|
Comment 5•10 years ago
|
||
Implementing the dialog element makes sense in my opinion because it is hard to polyfill correctly. Modal dialogs have to render all nodes but themselves (and descendants) inert. However, without implementing showModal, one cannot make nodes inert by script. Workarounds are to listen for focus changes and setting the focus back onto the dialog whenever it leaves and to prevent further events from happening outside the dialog by putting a backdrop between the dialog and the rest of the document. Finally, one usually adds aria-hidden="true" onto the non-dialog part of the document. This raises a number of problems, though: 1) There might be another way to access the document that is not fully inert than by just preventing mouse and keyboard events and controlling the focus. 2) The dialog element cannot be a descendant of anything that has to be made inaccessible (due to the way aria-hidden works). 3) Trapping the focus inside the dialog means that one cannot access the location bar with the tab key without closing the dialog first.
Updated•10 years ago
|
Reporter | ||
Comment 6•10 years ago
|
||
Chrome and Opera now have mostly complete support, including support for <form method="dialog">. They omit support for specifying an optional anchor point argument on .show() and .showModal(). There is MDN reference documentation at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog and https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement.
Comment 7•9 years ago
|
||
This would be very useful to have for accessibility, too. It would mittigat e the need for web authors to create their own dialog widgets and have to use hacks like aria-hidden to hide everything *outside* the dialog widget from assistive technologies for people with disabilities. It is a real nuisance to deal with from both an evangelism and technical standpoint, and having the native html:dialog element implemented would hugely improve the lives of many many people.
Updated•9 years ago
|
With the planned removal of showModalDialog, this feature should get implemented rather than forcing applications to polyfill dialog functionality. See https://bugzilla.mozilla.org/show_bug.cgi?id=981796 for more on the removal of showModalDialog.
I think the native dialog element is a great idea. Wouldn't it be awesome to have the ability to use something that is native to the platform instead of having to rely on libraries to implement this functionality for us? I would much rather use something that is native to the web platform compared to having to rely on a library. It is now in Chrome stable, and if it was implemented in Firefox then developers could actually start to use it(chrome and firefox basically own the browser market together).
Comment 10•9 years ago
|
||
Also, native dialogs would be even more useful on FirefoxOS
Comment 11•8 years ago
|
||
Seeing interest in this spike again recently, tracking this with DevAdvocacy.
Comment 12•8 years ago
|
||
Probably someone could take this and implement functions other than dialog.showModal(). To implement dialog.showModal() correctly, we need to convert our fullscreen stack into top layer stack, and handle both fullscreen and modal dialog there. To having the fully-implemented top layer stack, we may need to finish bug 1195213 first. And I don't think other parts of <dialog> should be blocked by that.
Updated•7 years ago
|
Comment 13•7 years ago
|
||
Leaving it here as reference.
Updated•7 years ago
|
Updated•7 years ago
|
Comment 14•7 years ago
|
||
That bug should be considered to be a blocker of bug 1322939.
Updated•7 years ago
|
Comment 15•7 years ago
|
||
I can't seem to find an "intent to implement" for this feature, did you send one?
Comment 16•7 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #15) > I can't seem to find an "intent to implement" for this feature, > did you send one? I've sent one on Monday, it's still awaiting approval unfortunately.
Comment 17•7 years ago
|
||
> I've sent one on Monday, it's still awaiting approval unfortunately.
I still haven't seen it, so I suspect something might have gone wrong.
Could you file a bug about that, or notify the people responsible
somehow?
Meanwhile, I can send it for you if you want.
Comment 18•7 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #17) > > I've sent one on Monday, it's still awaiting approval unfortunately. > > I still haven't seen it, so I suspect something might have gone wrong. > Could you file a bug about that, or notify the people responsible > somehow? Looks like non-member posts take forever to get moderated. I've joined the list and posted, and it worked: https://groups.google.com/forum/#!topic/mozilla.dev.platform/vTPGW1aJq24
Updated•7 years ago
|
Comment 19•7 years ago
|
||
Nice to see activity on the dependencies! Please ping MarcoZ (back next week) for accessibility reviews.
Comment 20•7 years ago
|
||
A key aspect to ensuring the usability/accessibility of the Firefox dialog implementation is to move focus to the dialog container when a dialog is displayed. This is not what is currently specced, but there is a related issue https://github.com/whatwg/html/issues/1929 I would suggest that firefox should implement whats best for users rather than whats in the spec, in this regards. Another consideration is moving focus back to the triggering element when a dialog is dismissed.
Comment 21•7 years ago
|
||
(In reply to steve faulkner from comment #20) > A key aspect to ensuring the usability/accessibility of the Firefox dialog > implementation is to move focus to the dialog container when a dialog is > displayed. This is not what is currently specced, but there is a related > issue https://github.com/whatwg/html/issues/1929 I would suggest that > firefox should implement whats best for users rather than whats in the spec, > in this regards. > > Another consideration is moving focus back to the triggering element when a > dialog is dismissed. After further discussion on this spec bug https://github.com/whatwg/html/issues/1929 There appears to be rough consensus around implementing default focus on the dialog element.
Comment 23•7 years ago
|
||
I've been asked a colleague at Google to make a note about the spec's use of the concept "inert" - and, that as part of implementing `dialog`, we should use the same infrastructure to implement the "inert" attribute as per: https://github.com/WICG/inert I'm super supportive of that idea, as inert seems super useful (and it's being implemented in Chrome).
Comment 24•7 years ago
|
||
Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=710523#c5 Don't forget to apply `contain: strict` style, after https://bugzilla.mozilla.org/show_bug.cgi?id=1150081 implemented.
Comment 26•6 years ago
|
||
I think this has been available in stable release under the flag “dom.dialog_element.enabled”?
Comment 27•6 years ago
|
||
(In reply to Zhaolin Yu from comment #26) > I think this has been available in stable release under the flag > “dom.dialog_element.enabled”? Yeah, there's an incomplete implementation available under that flag.
Comment 28•6 years ago
|
||
Opera Presto does not support this.
Comment 29•6 years ago
|
||
Unassigning to reflect real status.
Comment 30•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Comment 31•6 years ago
|
||
I'm getting requests for this. It would allow Authors to remove a bunch of (sadly too often crappy and inaccessible) JavaScript from their websites.
Updated•6 years ago
|
Comment 32•6 years ago
|
||
Found a bug: You can't style the showModal() backdrop via "dialog::backdrop". Should this be a separate issue? Test case: https://demo.agektmr.com/dialog/
Comment 33•6 years ago
|
||
(In reply to Starbeamrainbowlabs from comment #32) > Found a bug: You can't style the showModal() backdrop via > "dialog::backdrop". Should this be a separate issue? > > Test case: https://demo.agektmr.com/dialog/ That’s not implemented as `<dialog>` isn’t yet fully implemented (bug 1322939). Also, we know that `dialog::backdrop` isn’t yet supported: https://developer.mozilla.org/docs/Web/CSS/::backdrop#Browser_compatibility
Comment 34•6 years ago
|
||
Many thanks for that, @ExeBoss. I'll follow that bug then. I'd have thought I'd be implemented already, but I guess for now I'll use a polyfill :-/
Comment 35•5 years ago
|
||
Is there any progress with this? I'm worried it may be removed from the spec due to lack of support. See @domenic's comments https://github.com/whatwg/html/issues/3567#issuecomment-451451406
Comment 36•5 years ago
|
||
I think we are still interested in implementing it, especially given there are developer requests. IIUC, the remaining pieces are focusing steps, modal, and accessibility. Focusing steps seem to be reasonably straightforward itself. Since we don't support inert, we can ignore the inert check for now. I have no idea how much work accessibility would take. Modal is probably the most non-trivial one. It requires some degree of inert support, and it needs some refactor to the top layer stack as mentioned in comment 12. However, since we are probably not going to support multiple fullscreen element from different subtree (bug 1195213), some of the interaction between fullscreen and modal dialog can become tricky again, which may need some more thought.
Comment 37•5 years ago
|
||
(Added a comment in whatwg/fullscreen#140 for interaction between modal dialog and fullscreen.)
Updated•5 years ago
|
Comment 38•5 years ago
|
||
I just discovered <dialog>
today. It would solve a specific problem I have with my Web app perfectly. (My particular concern is solved by the "pending dialog” stack to handle the case of multiple modal dialogs.) I would love to see this implemented and am now worried about it being removed from the HTML spec due to only Chrome implementing it. Please prioritize this accessibility feature and affirm this feature's presence in the HTML spec.
Updated•5 years ago
|
Comment 39•5 years ago
|
||
Moving to DOM to reflect correct ownership.
Comment hidden (advocacy) |
Comment 41•5 years ago
|
||
The priority for this bug is not set yet. :hsinyi can you or somebody of your team set it, please?
Sebastian
Comment 42•5 years ago
|
||
(In reply to Sebastian Zartner [:sebo] from comment #41)
The priority for this bug is not set yet. :hsinyi can you or somebody of your team set it, please?
Meta bugs generally shouldn't be prioritized.
Comment 43•5 years ago
|
||
As Matthew explained, meta bugs usually don't get prioritized as well as a new feature request (enhancement type) which will go to our planning queue with PM.
Comment hidden (advocacy) |
Comment 45•5 years ago
|
||
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #43)
As Matthew explained, meta bugs usually don't get prioritized as well as a new feature request (enhancement type) which will go to our planning queue with PM.
Should someone create a new feature request for it? Happy to do so if that will help move this along.
Updated•4 years ago
|
Comment 47•4 years ago
|
||
This bug is 7 years old. I love to see this supported without flags, as it is in Chromium. I'd use this a lot if Firefox would support it too.
Comment 48•4 years ago
|
||
I use a <dialog> element for my web application, but I obviously want to support as many browsers as possible. Is this the current alternative?
https://github.com/niutech/showModalDialog
My apologies if there's a well-known way to do modals in Firefox that I'm unaware of.
Comment 49•4 years ago
|
||
Hi Jesse, showModalDialog
is considered deprecated, and support for it was removed from Chrome 43 and Firefox 56, see: https://developer.mozilla.org/en-US/docs/Web/API/Window/showModalDialog
This bug report is only about the <dialog>
HTML element and comments should be restricted to that.
Comment 50•4 years ago
|
||
Hi David,
Thanks for the response. Sorry if I was unclear. What I meant was that I'm not sure what the standard alternative to the <dialog> element is.
Comment 51•4 years ago
|
||
In case anyone else is in the situation I was in, this is what I used:
https://github.com/GoogleChrome/dialog-polyfill
It worked perfecly.
Comment 52•4 years ago
|
||
I've noticed the <dialog> element appears to now be enabled by default in Nightly, but it's incompatible with our PWA. I filed issue 1656874 about that.
Comment 53•4 years ago
|
||
In case it helps, I tested the Chrome <dialog>
demo in FF Nightly and it seems to work fine. Looking forward to seeing this land in general FF!
Comment 54•4 years ago
|
||
I look forward to this too!
Comment 55•3 years ago
|
||
Is there any estimate of when this will be enabled in general releases?
We have some internal new UI for Thunderbird where we could make use of it if it's stable enough...
Comment 56•3 years ago
|
||
There are a couple minor spec issues but it's always enabled for chrome code anyways, iirc.
Comment 57•3 years ago
|
||
Hello, I find a inner-state bug when combine <dialog>
and CSS filter
:
- an
<dialog>
is under an element havingstyle="filter: invert(1);"
- the dialog has a child element with
position: fixed
- call
dialog.showModal()
- then the child element with
position: fixed
will not be fixed, but act somehow like "position: absolute" - if use JS to modify its styles to
position: absolute
and then rollback, then the newposition: fixed
will work as expected.
Here's my test demo: https://jsfiddle.net/rvnz4q9e/
I've tested Firefox 90, 91.0esr, and 93 nightly.
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 58•2 years ago
|
||
It's been enabled by default as per bug 1733536.
Updated•2 years ago
|
Comment 59•2 years ago
•
|
||
Hsin-Yi Tsai (triage owner), could you ask someone to comment on this bug?
(Thunderbird) Bug 1754094 - (Modal) HTML5 dialogs do not contain their tab sequence - cycles dozens of window stops before returning to the dialog
Per https://www.w3.org/TR/wai-aria-practices/#dialog_modal, (modal) dialogs must contain their tab sequence, i.e. pressing tab must cycle only within the dialog.
Comment 60•2 years ago
|
||
(In reply to Thomas D. (:thomas8) from comment #59)
Hsin-Yi Tsai (triage owner), could you ask someone to comment on this bug?
Bug 1754094 - (Modal) HTML5 dialogs do not contain their tab sequence - cycles dozens of window stops before returning to the dialog
Per https://www.w3.org/TR/wai-aria-practices/#dialog_modal, (modal) dialogs must contain their tab sequence, i.e. pressing tab must cycle only within the dialog.
Sure thing.
Emilio and Sean have been working on this feature. Let's start from them.
Comment 61•2 years ago
|
||
That seems a bug about thunderbird, what am I missing? Modal dialogs trap focus from the pages point of view (makes everything else on the page inert). But we don't want to prevent the user from interacting with the browser chrome just because a page has called dialog.showModal, that'd be pretty user hostile.
Thunderbird can use dialog and it'd trap focus like dialogs trap focus on Firefox. Again, i feel like I'm missing something.
Comment 62•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #61)
That seems a bug about thunderbird, what am I missing? Modal dialogs trap focus from the pages point of view (makes everything else on the page inert). But we don't want to prevent the user from interacting with the browser chrome just because a page has called dialog.showModal, that'd be pretty user hostile.
Thunderbird can use dialog and it'd trap focus like dialogs trap focus on Firefox. Again, i feel like I'm missing something.
https://github.com/w3c/aria-practices/issues/1772 is the relevant discussion about whether to prevent access to the browser chrome while a modal dialog is open.
Comment 63•5 months ago
•
|
||
Hi Dennis, is there a still reason that we think this "meta" bug is webcompat:P2, especially given that <dialog> was enabled already in bug 1733536?
Comment 64•4 months ago
|
||
Sorry, Hsin-Yi, I somehow missed your ni? :) I don't think we have any known active breakage on this (also supported by the fact that we don't have a Knowledge Base bug for this), but I've flagged this for next Monday's triage meeting so I can sync with the others about this.
Keeping my ni? active until then.
Comment 65•4 months ago
|
||
Doesn't seem like this is a WebCompat issue anymore, so unsetting the flag.
Description
•