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

Hi Tess! Thanks to you and Peter for taking a look! Your point about the connection with IndieUI/AOM is well-taken, and I'll reach out to those folks to learn more about the history there. Also, some of the specific API feedback pieces from the minutes are great and we'll definitely take those into account.

I worry that one big thing that was missed in the review was [our section on why synthesizing an event doesn't work that well](https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md#automatically-translating-all-close-signals-to-esc). As that section mentions, to do such a translation, the browser needs to know whether a given gesture/keypress/back button/etc. is a close signal, or is something else (like a navigation on Android, or a scroll on iOS).

To do this, the web developer needs to provide some signal to the browser that they're in a situation where close signals make sense. We've provided that via `new CloseWatcher()`. You could imagine other routes for giving the browser this signal, but fundamentally such a signal is needed. (Indeed, I think your suggestion about detecting elements with ARIA roles is in this category, but that'd be rather unprecedented: ARIA roles currently only affect accessibility technology, and do not change behavior, which is something I believe the ARIA WG has worked hard to preserve so that people don't abuse accessibility annotations to achieve a given user experience for non-AT users.)

Another thing to consider is the [abuse prevention discussion](https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md#abuse-analysis). Abuse prevention is relatively easy with an imperative API like this, where there's a clear time at which the "trap" could be installed (i.e., upon the construction of the `CloseWatcher` object). It gets harder with other APIs, such as ones based on the presence or absence of elements in the DOM. For example, we don't want to modify generic DOM insertion code to throw if someone inserts too many elements with a given ARIA role.

Finally, I'm curious about the implication that this approach is very complex/complicated. Would you be able to say more? From my point of view and that of framework authors I've discussed this with, this is basically "as simple as possible": a constructor to signal that you want to watch, and an event to get notified of the thing you're watching for. Framework authors generally preferred this to the complexity they'd have to introduce into their application to differentiate between different types of <kbd>Esc</kbd> keypresses, or coordinate which of several active components a given `document`-targeted <kbd>Esc</kbd> is meant to close, or insert elements like `<dialog>` into the DOM which might not fit with their application structure. I wonder if we shot ourselves in the foot here by writing too long of an explainer...

Indeed, although I recognize thinking on the extensible web manifesto has evolved over time, I think this is one of the cases where it really shines: excavating simple primitives that underlie elements like `<dialog>`, or the proposed [`<popup>` light dismiss behavior](https://github.com/openui/open-ui/issues/320), and making them first-class so that everyone can use them without needing to rely on browser magic such as synthetic <kbd>Esc</kbd> keys or elements with special privileges.

Let us know what you think!


-- 
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#issuecomment-844384755