Bug 840640 (dialog-element)

[meta] Implement the HTML5 dialog element

ASSIGNED
Assigned to

Status

()

Core
Layout
ASSIGNED
5 years ago
a month ago

People

(Reporter: Dave Hodder, Assigned: ntim)

Tracking

(Depends on: 6 bugs, Blocks: 3 bugs, 4 keywords)

Trunk
dev-doc-needed, DevAdvocacy, html5, meta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-chrome][parity-opera])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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.)
(Reporter)

Updated

5 years ago
Blocks: 568516
Sounds like something humph would be interested in :)
Component: Layout → DOM: Core & HTML
(Reporter)

Updated

5 years ago
Keywords: html5
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Updated

5 years ago
Keywords: dev-doc-needed
(Reporter)

Comment 2

5 years ago
Created attachment 720266 [details]
HTML testcase

Comment 3

4 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

4 years ago
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → Layout
Ever confirmed: true

Comment 4

4 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/
Attachment #720266 - Attachment mime type: text/plain → text/html
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.
See Also: → bug 1064843
(Reporter)

Comment 6

3 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.
Whiteboard: [parity-chrome][parity-opera]
Blocks: 981796

Comment 7

3 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.
See Also: → bug 1105857
Depends on: 1064843

Comment 8

2 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.
(Reporter)

Updated

2 years ago
Blocks: 802882
Comment hidden (me-too)

Comment 10

2 years ago
Also, native dialogs would be even more useful on FirefoxOS
Depends on: 1236828

Comment 11

a year ago
Seeing interest in this spike again recently, tracking this with DevAdvocacy.
Keywords: DevAdvocacy
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

a year ago
Blocks: 1230801
(Assignee)

Updated

8 months ago
Assignee: nobody → ntim.bugs
Status: NEW → ASSIGNED
(Assignee)

Comment 13

8 months ago
Created attachment 8817913 [details] [diff] [review]
WIP (doesn't compile)

Leaving it here as reference.
(Assignee)

Updated

8 months ago
Alias: dialog-element
Keywords: meta
Summary: Implement the HTML5 dialog element → [meta] Implement the HTML5 dialog element
(Assignee)

Updated

8 months ago
Depends on: 1322938
(Assignee)

Updated

8 months ago
Depends on: 1322939
(Assignee)

Updated

8 months ago
Depends on: 1322940
(Assignee)

Updated

8 months ago
Depends on: 1322941
No longer depends on: 1064843, 1236828
(Assignee)

Updated

8 months ago
Depends on: 1195213
That bug should be considered to be a blocker of bug 1322939.
No longer depends on: 1195213
(Assignee)

Updated

8 months ago
Attachment #8817913 - Attachment is obsolete: true
(Assignee)

Updated

8 months ago
Depends on: 1322946
(Assignee)

Updated

8 months ago
Depends on: 1322947
I can't seem to find an "intent to implement" for this feature,
did you send one?
(Assignee)

Comment 16

8 months 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.
> 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.
(Assignee)

Comment 18

8 months 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
(Assignee)

Updated

8 months ago
No longer depends on: 1322940, 1322941
(Assignee)

Updated

8 months ago
Depends on: 1324958
Nice to see activity on the dependencies! Please ping MarcoZ (back next week) for accessibility reviews.

Updated

7 months ago
Depends on: 1330659

Comment 20

7 months 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 months 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.

Updated

4 months ago
Duplicate of this bug: 1355741
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).
(Assignee)

Updated

2 months ago
Depends on: 921504

Comment 24

a month 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.

Updated

a month ago
Duplicate of this bug: 1379446
You need to log in before you can comment on or make changes to this bug.