Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Close signals #18

Closed
domenic opened this issue Dec 10, 2020 · 4 comments
Closed

Close signals #18

domenic opened this issue Dec 10, 2020 · 4 comments

Comments

@domenic
Copy link

domenic commented Dec 10, 2020

Introduction

Modals are UI components that are layered on top of all other content and take interaction focus. Some examples are:

  • a <dialog> element, especially the showModal() API;
  • a sidebar menu;
  • a lightbox;
  • a custom picker input (e.g. date picker);
  • a custom context menu;
  • fullscreen mode.

An important common feature of these modals is that they are designed to be easy to close, with a uniform interaction mechanism for doing so. Typically, this is the Esc key on desktop platforms, and the back button on some mobile platforms (notably Android). Game consoles also tend to use a specific button as their "close/back" button. Another case is VoiceOver users on iOS, who have a special dismiss gesture.

We define a close signal as a platform-mediated interaction that's intended to close a modal. This is distinct from page-mediated interactions, such as clicking on an "x" or "Done" button, or clicking on the backdrop outside of the modal.

Currently, web developers have no good way to handle these close signals for their own modals. This is especially problematic on Android devices, where the back button is the traditional close signal. Imagine a user filling in a twenty-field form, with the last item being a custom date picker modal. The user might click the back button hoping to close the date picker, like they would in a native app. But instead, the back button navigates the web page's history tree, likely closing the whole form and losing the filled information.

This explainer proposes a new API to enable web developers, especially component authors, to better handle these close signals. It also contemplates an alternate proposal that does not involve introducing a specific new API for close signals, but instead bundles these semantics with new higher-level APIs for modals, which would hopefully solve other problems like top-layer behavior or focus trapping. (But, the explainer does not itself tackle those problems.)

Read the complete Explainer.

Feedback

I welcome feedback in this thread, but encourage you to file bugs against the Explainer.

@tomayac
Copy link

tomayac commented Dec 11, 2020

Some platforms have no uniform close signals; to our knowledge, iOS falls in this category.

The only close signal, apart from buttons that are universally required, are swipe down gestures for card-like modals, according to the Apple Human Interface Guidelines.

@jnurthen
Copy link

jnurthen commented Feb 3, 2021

Note - iOS has a close gesture when VO is running

Dismiss an alert or return to the previous screen | Two-finger scrub (move two fingers back and forth three times quickly, making a “z”)

@domenic
Copy link
Author

domenic commented Apr 9, 2021

Hey folks, I've updated the proposal recently, with the updates summarized at w3ctag/design-reviews#594 (comment) . Feel free to take another look, and please voice your support if you think this is something worth incubating in the WICG!

@cwilso
Copy link
Member

cwilso commented Sep 7, 2021

@cwilso cwilso closed this as completed Sep 7, 2021
tidoust added a commit to w3c/browser-specs that referenced this issue Sep 13, 2021
This update adds CSS Cascade 6 and drops CSS Scoping 2 as a result (the latter
spec now redirects to the former).

It also adds the Scripting Policy and Close Watcher API. The two specs are
still at early stages but development is active and proposals are being backed
by implementers, see:
WICG/proposals#18
WICG/proposals#36
tidoust added a commit to w3c/browser-specs that referenced this issue Sep 13, 2021
This update adds CSS Cascade 6 and drops CSS Scoping 2 as a result (the latter
spec now redirects to the former).

It also adds the Scripting Policy and Close Watcher API. The two specs are
still at early stages but development is active and proposals are backed
by implementers, see:
WICG/proposals#18
WICG/proposals#36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants