Thoughts on close requests for dialogs

Manuel published "Close requests, close watchers, and the dialog element". I learned some things, have some questions and needed to structure my thoughts. So here we go!

Chrome now ships a new closedby attribute for dialog elements.

MDN Compat Data (source)

Browser support info for closedby

134	134	134	Non	Nö	Nein	Nö	Non	134

The new attribute accepts the values none, closerequest and any.

<dialog closedby="closerequest">Heyoooo! 👋</dialog>

Per spec, dialogs can now be closed via "close requests" (closerequest) or "close requests and any click outside of the dialog" (any).

What's a close request?

The spec includes the following on close requests as:

In an implementation-defined (and likely device-specific) manner, a user can send a close request to the user agent. This indicates that the user wishes to close something that is currently being shown on the screen, such as a popover, menu, dialog, picker, or display mode.

Close requests signal the browser that you want to get rid of whatever is on screen. They can be triggered with different actions depending on the device and user agent.

A close request will be sent on a desktop computer with a keyboard by pressing ESC. Makes sense!

Here's a trick question, though: how often does something pop open on a site, and you can't close it with the ESC key? For me, it's quite often, and I'm mad about it.

It's different on a phone because there's no ESC key to press. Here's the spec again telling what "might" send a close request on mobile devices:

The back button or gesture on certain mobile platforms such as Android.

I played around with the new dialog behavior on my Android phone.

Now, do I expect that a dialog closes when I swipe from left to right or hit the "back" button on my phone? I don't know. Let me hide behind my chair and whisper a silent "maybe?".

Web development is messy, and many sites reimplement modals / dialogs instead of using the dialog element. I don't think the dialog element is general knowledge and many devs don't realize that a custom dialog implementation almost always sucks. Toggling the display property on a fixed container does the trick, right? Wrong.

I haven't counted or checked, but I expect that the internet comes with way more custom modals than platform-first dialog elements. Will custom JavaScript dialogs close when I hit the ESC key? Very unlikely. Will sites shipping these custom implementations perform different actions after I press my phone's "back" button depending on if there's an open dialog? I doubt it.

We'll soon have "good platform dialogs" that come with UX / a11y sprinkles and then we will have the broken rest. It's a different kind of broken this time, though.

Usually, custom implementations aren't focusable, don't announce valuable content in a screen reader, can't be scrolled, [the list goes on]... of course, all these issues suck, but this isn't the situation we have here.

Custom dialog implementations aren't just broken now. Native and custom dialogs will behave differently.

The mobile "back" button could now close a dialog or navigate to a different URL, maybe even a different origin. And you'll never know what'll happen without trying.

Let's take cookie banners as an example:

• You search for something on the Internet.
• You click the first link.
• You swipe or hit "back" to close the cookie banner.
• Whooops... you're back on the search results page because the cookie banner doesn't react to close requests.
• You stop hitting "back" to close dialogs altogether.

I don't have the answers or a solution, but it feels risky to me to adopt the "back" action to close a dialog. Will you start closing dialogs with the "back" button?