[w3ctag/design-reviews] Earn design review of modal close signals/ModalCloseWatcher (#594)

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](https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md#bundling-this-with-high-level-apis) 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?

  - Explainer¹ (minimally containing user needs and example code): https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md

  - Security and Privacy self-review²: https://github.com/slightlyoff/history_api/blob/master/history_and_modals_spq.md

  - GitHub repo (if you prefer feedback filed there): https://github.com/slightlyoff/history_api/ for now
  - Primary contacts (and their relationship to the specification):
      - Domenic Denicola (@domenic), Google, spec person
      - Nate Chapin (@natechapin), Google, implementor
      - Dima Voytenko (@dvoytenko), Google, framework author who spurred us to consider this problem and started the explainer work
  - Organization/project driving the design: Chromium
  - External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Will update when we have some

Further details:

  - [x] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/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**

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/594