Enable support for<dialog> to be dismissed using the back button #5667
Comments
|
This is actually already supported in the specification: see https://html.spec.whatwg.org/#canceling-dialogs . It's not mandated, because the HTML Standard cannot mandate how browser UI like the back button behaves. But it's definitely allowed, if browsers want to implement this. |
|
The current work on CloseWatcher integration with the dialog element should implement the desired behavior here, right? |
|
Yes! And the spec support for that is in https://wicg.github.io/close-watcher/, which I hope to add to HTML soon-ish. |
|
Regarding the question of which issues in #4184 (comment) should be considered blocking for writing up a spec of https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic : I don't think this is blocking. |
|
This would be closed by #9462 right? |
This adds the generic close request concept, which allows interfaces like the Esc key, or back gestures and buttons, to be interpreted as closing various "close watchers". Two existing constructs are converted to close watchers: modal dialog elements, and auto popovers. Additionally, this adds the CloseWatcher API, which lets web developers create their own close watchers. Note that the close request steps formalize previously-informal parts of the Fullscreen API Standard. The specification text here is largely ported from https://github.com/WICG/close-watcher/blob/3a18e6811528d349df27a3e7b06b8dc018638c4c/spec.bs. Updates include: * Requiring keyup to be the close request event for user agents which use the Esc key as a close request, per discussions in #9143. * Introducing requestClose(), per WICG/close-watcher#28. * Renaming the "close signal" concept to "close request". * Changing the "close request steps" to all be in a single queued task. This change to dialog behavior is a potential compatibility risk, especially since it can cause the cancel event to be skipped if there has been no user activation since the last time it was canceled, or multiple dialogs to be closed at once. However, Chromium data shows these risks to be negligible: * https://chromestatus.com/metrics/feature/timeline/popularity/4422 shows 0.000015% of pages impacted by skipped cancel events. * https://chromestatus.com/metrics/feature/timeline/popularity/4423 shows 0.000007% of pages impacted by skipped cancel events that would otherwise call preventDefault(). * https://chromestatus.com/metrics/feature/timeline/popularity/4424 shows between 0.000000% and 0.000001% of pages impacted by multiple dialogs closed. Closes #9143. Closes #5667.
One of the biggest shortcomings, in my opinion, of HTML over native mobile apps is the behaviour of the back button in relation to popups / pop-outs.
Currently developers have to use the History API to be able to dismiss a popup when the back button is pressed. I think this adds extra complexity and also it is incorrect since the popup isn't really a new history state.
I propose that the
<dialog>element should have native back button support, so that whenever a dialog is manually triggered on a page, it can be dismissed by using the back button. The<dialog>element could contain any content, such as a popup or a custom dropdown menu.In this case the back button would simply act as an "escape" or "cancel" key - there would be no history state added when the dialog is triggered and also it would not re-trigger if the forward button is pressed.
This would bring the behaviour in line with how native apps work, as users are accustomed to using the back button to dismiss popups. But this experience isn't the same on mobile browsers - I can imagine users will have been pressing the back button on a popup, thinking it will make it go away, but instead navigating to the previous page.
Perhaps this feature could be enabled on mobile/touch devices only? Currently in mobile browsers you can dismiss a
<select>and some input controls (such asdate) using the back button.The text was updated successfully, but these errors were encountered: