Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to Ship : HTML5 <dialog> element (Nightly Only)

231 views
Skip to first unread message

Sean Feng

unread,
Jun 24, 2020, 4:05:04 PM6/24/20
to dev-pl...@lists.mozilla.org
Intent to Ship (Nightly Only) : Dialog Element

Hi All,

In bug 1645046 <https://bugzilla.mozilla.org/show_bug.cgi?id=1645046>, I
intend to turn html5 <dialog> element on by default in Nightly. It has
been developed behind the dom.dialog_element.enabled preference.

Meta Tracking Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

This is Nightly only because two things needs adjustment in our
implementation.

1. The inert element isn't supported (bug 921504 -
https://bugzilla.mozilla.org/show_bug.cgi?id=921504).

 - For modal dialog, elements that are not part the dialog should be
mark as inert, so these elements gain the inert-ness and can't be
focused. Since we don't have inert supported yet, users could use tab to
move focus out of the dialog, which is not expected.

 - Next Step: The implementation of inert element is going to be
started soon (I think), and we can also discuss to support the
inert-ness without the supporting of inert element

2. We currently use a temporary solution for the layout of modal dialog.
(bug 1637310 - https://bugzilla.mozilla.org/show_bug.cgi?id=1637310).

  - Currently the spec defines modal dialog as an absolute element,
along with some weird calculation requirement to make the element
centered. This modal dialog layout felt like a hack to us, so we didn't
follow it, and instead, we used a temporary solution
(https://bugzilla.mozilla.org/show_bug.cgi?id=1642364) to make the modal
dialog as a centered fixed element.

  - Next Step: The CCSWG agreed to switch modal dialog to be a centered
fixed element
(https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060),
which is the same as the temporary solution we applied in bug 1642364.
So the temporary solution may become a permanent solution after things
have been finalized in spec.

*Status in other browsers*
Chrome has it enabled by default since Release 37
https://www.chromestatus.com/feature/5770237022568448

*web-platform-tests*:
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/interactive-elements/the-dialog-element,
We have them all enabled and passing except for those layout and inert
related ones.

*Spec* - https://html.spec.whatwg.org/multipage/#the-dialog-element

This feature was previously discussed in
https://groups.google.com/d/msg/mozilla.dev.platform/vTPGW1aJq24/JnEnoH3BEAAJ

James Teh

unread,
Jun 24, 2020, 4:19:53 PM6/24/20
to Sean Feng, dev-platform
While this doesn't need to block shipping in Nightly, I think we should
consider advocating for the focus behaviour to be changed (and changing it
in Firefox if we can get it into the spec) before we ship to release.

The currently specified behaviour (and what both Firefox and Chrome
implement) is to focus the first focusable element in the dialog. However,
there are a few major problems with this, including:
1. This means a tabindex="-1" element could get focus, which is focusable
but not in the tab order. That's particularly strange if this gets focus in
preference to something which *does* participate in the tab order.
2. The first focusable element could be a long way down the page; e.g. a
dialog with a lot of preamble text and a form field or button after that
text. That is particularly problematic for screen reader users because that
will direct their reading cursor to the focused control, so they will
potentially not realise they're missing content above it. It might even
cause the page to scroll visually.

What I (and others in the accessibility community) am proposing is that the
dialog element itself should get focus, unless something within the dialog
has autofocus set, in which case we should focus that. There's a spec issue
for this, but it stalled:
https://github.com/whatwg/html/issues/1929

Another concern is that when the dialog is dismissed, focus gets thrown
back to the document. Instead, I think it should be returned to the element
which had focus before the dialog was shown, which is the recommended
pattern for good accessibility of dialogs. I don't think there is a spec
issue for this yet.

Jamie
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Sean Feng

unread,
Jun 25, 2020, 11:04:38 AM6/25/20
to James Teh, dev-platform
Yeah, agreed.

I just filed https://github.com/whatwg/html/issues/5678 for moving the
focus back to what had focused before when the dialog is dismissed.
0 new messages