Add dialog light dismiss behavior

[mfreed7]

This adds a few things:

• A closedby attribute that can be used to control the light dismiss behavior of dialogs:

  1. <dialog closedby=none> - no user-triggered closing of dialogs at all.
  2. <dialog closedby=closerequest> - user pressing ESC (or other close trigger) closes the dialog
  3. <dialog closedby=any> - user clicking outside the dialog, or pressing ESC, closes the dialog. Akin to popover=auto behavior.
  4. <dialog> - i.e. no closedby attribute - default/old behavior. Behaves like closedby=closerequest for modal dialogs, and closedby=none for modeless dialogs.

• This PR also (per the request) adds a dialog.requestClose() which fires the cancel event, and then (if that isn't cancelled) fires the close event and closes the dialog.

• I also consolidated the "light dismiss" activities into one algorithm, which will need to be called by Add popover light dismiss integration w3c/pointerevents#460 if that ever gets some attention.

Some interesting related links:

• WIP dialog closedby attribute spec #10157 - much of this PR was lifted from @lukewarlow's PR
• Add light dismiss functionality to <dialog> #9373 - the WHATWG discussion
• Bikeshed a name for "light dismiss for dialog" openui/open-ui#834 - the OpenUI discussion
• Naming for the *attribute* to enable "light dismiss for dialog" openui/open-ui#960 - naming discussion to get to closedby
• Naming for the *value* for the attribute that means "just close with ESC" openui/open-ui#961 - naming discussion to get to closerequest

Closes #9373

• At least two implementers are interested (and none opposed):
  • Chromium
  • WebKit: Presumably supportive, based on @annevk reviews. No official position
  • Gecko: @smaug---- has said he would review, so TBD. No official position
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/semantics/interactive-elements/the-dialog-element?label=master&label=experimental&aligned&q=dialog-closedby.tentative.html%20or%20dialog-popover-closedby-complex.tentative.html%20or%20dialog-popover-closedby-simple.tentative.html%20or%20dialog-requestclose.tentative.html
• Implementation bugs are filed:
  • Chromium: https://crbug.com/376516550
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1936940
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=284592
• MDN issue is filed: Add documentation of new dialog light dismiss behaviors mdn/content#37196
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dnd.html ( diff )
/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )
/semantics-other.html ( diff )

[domenic]

This is exciting! Unfortunately I am going OOO for a week starting ~now, so won't get a chance to review too soon. Hopefully others will be able to help with some reviews, but I would like to get a chance to carefully review the close watcher integration, etc. before this lands.

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

[keithamus]

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

Looks like CloseWatchers get a mutable enabled value, which is toggled whenever closedby is set to the applicable values - when false it skips the events and returns early. IMO this seems to nicely side-skirt the stacking issues around mutation of the attribute without adding lots of complexity in either the consuming elements and/or having some messy algorithms to insert mid-way into a stack.

[keithamus]

This looks great to me!

[mfreed7]

This is exciting! Unfortunately I am going OOO for a week starting ~now, so won't get a chance to review too soon. Hopefully others will be able to help with some reviews, but I would like to get a chance to carefully review the close watcher integration, etc. before this lands.

That's totally fine - no rush. I did this one in the opposite order that I usually do: spec first, prototype after. So I'm moving on to prototype it now, which might reveal other flaws. But I thought since @lukewarlow had gotten the spec into such decent shape, that I'd clean it up and open the PR in case folks saw other flaws there that I could address in the prototype.

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

As @keithamus said, I just kept what @lukewarlow did in the original PR, and used a new enabled state on CloseWatcher. I haven't implemented that yet, but it seems reasonably straightforward. But let me know if you see any flaws.

[annevk]

There's very inconsistent spelling of states here. They should match the capitalization and words of how they are introduced. And should typically be followed by the word state (though that's not linked).

[annevk]

Also, perhaps the statement of fact is better as a note?

[mfreed7]

There's very inconsistent spelling of states here. They should match the capitalization and words of how they are introduced. And should typically be followed by the word state (though that's not linked).

Yep, I agree. I fixed them all up, I think. Please let me know if you see any others I missed. All are now lowercase.

Also, perhaps the statement of fact is better as a note?

Sorry - can you help me understand this? Which "statement of fact"?

[mfreed7]

Gentle ping on this PR. All checkboxes are checked and it has an editor approval.

[lukewarlow]

Fwiw regarding implementor interest I raised mozilla/standards-positions#998 and WebKit/standards-positions#329

[mfreed7]

Fwiw regarding implementor interest I raised mozilla/standards-positions#998 and WebKit/standards-positions#329

Oh, thanks! I didn't realize those had been filed. I added them to the OP block.

[domenic]

Back from vacation, and merged! Please remember to send a PR renaming the tests from .tentative.

[stof]

Would closedBy=any also close when clicking on the backdrop pseudo-element or is it not considered a click outside the dialog ?

[lukewarlow]

Would closedBy=any also close when clicking on the backdrop pseudo-element or is it not considered a click outside the dialog ?

Yes, that closes the dialog. Here's a demo you can play around with in Chrome canary (w/ experimental web flag): https://jsfiddle.net/vco1mdth/

[lukewarlow]

PR to remove tentative from tests at web-platform-tests/wpt#50100

[mfreed7]

Back from vacation, and merged! Please remember to send a PR renaming the tests from .tentative.

Welcome back, and thanks!