#594: Early design review of modal close signals/ModalCloseWatcher

Visit on Github.

Opened Jan 7, 2021

HIQaH! QaH! TAG!

I'm requesting a TAG review of "Modal Close Signals".

A common feature of modals (dialogs, context menus, pickers, etc.) is that they are designed to be easy to close, with a uniform platform-wide interaction mechanism for doing so. Typically, this is the <kbd>Esc</kbd> key on desktop platforms, and the back button on some mobile platforms (notably Android). Not all platforms have such close signals, but for those that do, reacting to them is challenging to do correctly with current web APIs.

The explainer for modal close signals outlines the problem space, and goes into depth on one specific solution: a ModalCloseWatcher class, which provides a platform-agnostic way for developers to intercept these close signals. However, it also notes an alternative of bundling close signal handling into higher-level modal/popup APIs.

We'd appreciate any early feedback you have on both the problem space and the solution space. What do you think of our analysis of the problem space? Do you think ModalCloseWatcher is a good idea, or should we bundle into a higher-level API, or is there a third path we're not considering? Do you agree with our analysis that, even if we don't expose a ModalCloseWatcher class as a web API, the spec and implementation infrastructure could build off of something like it under the covers?

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG, most likely, or maybe as a HTML Standard pull request
  • The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG (HTML Standard)
  • Existing major pieces of multi-stakeholder review or discussion of this design: none yet
  • Major unresolved issues with or opposition to this design:
    • As mentioned above, we're unsure whether to expose a ModalCloseWatcher API vs. bundle into a higher-level API
    • We've recently discovered the situation with <dialog> is a bit more complicated than we thought, so that might impact the proposed <dialog> integration, and may cause other changes to the API out of a desire to keep symmetry with <dialog>: https://github.com/slightlyoff/history_api/issues/13
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue

Discussions

2021-01-Kronos

Minutes

Tess: I've been meaning to talk to jcraig about this; I'm reminded of IndieUI. This looks to be solving a narrower problem, though in a more imperative & complicated way.

Action: Tess to talk to jcraig

Peter: Thoughts on the API surface:

  • Activating a modal watcher via construction seems odd, would be nice to be able to construct one and activate it later, maybe something closer to the AbortController API.
  • No way to tell if a given watcher is the currently active one.
  • What happens when a watcher gets destroyed or a signalClose, but it's not the active watcher? e.g. a modal dialog opens another modal dialog, then the parent times out or gets a network event.

Tess recapped a bit about the accessibility events in AOM that got replaced with synthetic keyboard events, & some about the Indie UI "dismiss" event.

We contemplated the apparent fact that the web, for better or worse, has ended up with a 1990's desktop computer (monitor, keyboard, mouse) as it's basic abstraction. We agreed that having to add a bespoke XWatcher object to the platform for every niche X seems unoptimal, and suspect a simple, higher-level approach (like Indie UI's "dismiss" event) would enable browsers to solve the Android back button problem without all this complexity.

We also discussed the possibility of a higher level modal controller that also captures event, etc. e.g. all the things you need to do when starting a modal session, rather than small bits that you'd make one of those out of. Modal elements like Dialog could simply have one of those.

[Tess notes from rollout discussion, to turn into comment] We would prefer sending synthetic ESC key presses if/when the modal is either a real <dialog> or is marked up with ARIA. This problem seems the same as the increment/decrement synthetic arrow events thing in AOM—authors simply do what they should be doing anyway (provide aria attributes to say what their div soup is doing) and then the browser sends the events as needed.

2021-02-15

Minutes

Tess to write up a comment on the issue summarizing our previous discussion on this.

2021-05-Arakeen

Minutes

Peter & Tess talked about this at our last F2F but never posted public comments after that discussion; we've now done so.

2021-08-30

Minutes

Punt to plenary to get Tess' feedback

2021-09-Gethen

Minutes

The two of us looked at this in a previous F2F, and left a bunch of comments that Domenic addressed in a followup. Overall we both think this is basically fine, though we're still worried that "adding a bespoke <var>X</var>Watcher object to the platform for every <var>X</var> in the future wouldn't be great. Closed.