1733536 - Enable <dialog> element by default

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[Hsin-Yi Tsai (she/her) [:hsinyi]]

We enabled <dialog> in nightly in bug 1645046.
This is to track enabling the dialog element by default in release builds.

Comment 1

[Tom S [:evilpie]]

What are the required changes for enabling <dialog>?

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Tom Schuster [:evilpie] from comment #1)

What are the required changes for enabling <dialog>?

Per my best understanding, this accessibility issue https://github.com/whatwg/html/pull/4184 is the main blocker.
NI Emilio to confirm. :)

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Yep, that's right, getting consensus on that issue is the main blocker afaict.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1733536 - Enable <dialog> by default. r=smaug!,annevk!,Jamie!,sefeng!

It's been enabled on Nightly for a long while, and the only remaining
issue is about focus (https://github.com/whatwg/html/pull/4184 and co,
mostly). But:

• We get compat reports on release / ESR because of <dialog> not being
  enabled.

• Accessibility of hand-rolled dialogs is usually worse.

• I don't think tweaking the focus behavior slightly will have much
  compat fallout in practice, compared to websites just assuming
  <dialog> exists and is implemented, and breaking otherwise.

So, being pragmatic, I think it's probably better to have it enabled
than not. Thoughts?

Comment 5

[Mike Conca [:mconca]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Created attachment 9257348 [details]
Bug 1733536 - [rfc] Enable <dialog> by default. r=smaug!,annevk!,Jamie!,sefeng!

It's been enabled on Nightly for a long while, and the only remaining
issue is about focus (https://github.com/whatwg/html/pull/4184 and co,
mostly). But:

• We get compat reports on release / ESR because of <dialog> not being
  enabled.

• Accessibility of hand-rolled dialogs is usually worse.

• I don't think tweaking the focus behavior slightly will have much
  compat fallout in practice, compared to websites just assuming
  <dialog> exists and is implemented, and breaking otherwise.

So, being pragmatic, I think it's probably better to have it enabled
than not. Thoughts?

This sounds good to me. Pulling in Romain (Firefox front end) and Asa (a11y) for sign off.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Another point towards getting enabled it by default is that front-end code uses it really extensively already.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cca392552a57
Enable <dialog> by default. r=smaug,annevk,Jamie,sefeng

Comment 8

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/cca392552a57

Comment 9

[Pascal Chevrel:pascalc]

Is that an important enough platform feature to be mentioned in the Web platform section of our general release notes in beta/Release? Thanks

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Yea

Comment 11

[Pascal Chevrel:pascalc]

Release Note Request (optional, but appreciated)
[Why is this notable]: Improvement to our HTML support with positive webcompat impact
[Affects Firefox for Android]: ?
[Suggested wording]: The <dialog> HTML element already available on pre-release channels will become available on the release channel in version 98.
[Links (documentation, blog post, etc)]:

I am keeping the relnote flag on this one, I added a nightly specific note for the moment that will need a rewrite once we enter beta.

Comment 12

[Dipika]

Hello, I will be updating the docs (including the release note) for this fix. They can be tracked here: https://github.com/mdn/content/issues/12578#issuecomment-1048829230