Opening and closing dialogs without JavaScript

Because the dialog element can do everything a modal dialog needs, but could only be opened from a script. showModal puts it in the top layer, blocks the rest of the page, moves focus inside and closes it on Escape. You had to call showModal yourself though, and that meant a click listener on every button.

In a React project that quickly became more. A ref to the element, a function in the click handler, often state for open and closed that had to be kept in sync with the element, and a component holding button and dialog together because the button needs to know the ref. Many projects therefore reached straight for a library that rebuilds all of it a second time.

For popovers, popovertarget has offered a route without script for a while. Dialogs were left out, and that is exactly the gap command and commandfor close.

With a button carrying command="show-modal" and commandfor set to the dialog's id. A click on it does internally what showModal does, with focus, backdrop and top layer. A second button inside the dialog with command="close" and the same id closes it again.

The button does not have to sit next to the dialog. commandfor points through the id, so button and dialog can live in quite different places in the document, in different components too. What matters is that the id is unique and the target is an element that understands the command.

Chrome and Edge have supported the attributes since version 135, Firefox since 144 and Safari since 26.2. MDN has listed them as Baseline since December 2025, meaning newly available in all major browsers.

Six built-in ones, three for dialogs and three for popovers. On top of that come custom commands that start with two hyphens. A custom command does nothing by itself, it fires an event named command on the target, which states which command was meant.

That lets you drive your own components the same way as built-in elements. An image viewer can listen for --next and --previous, a video for --mute. The button stays a button with text and focus, and the script sits in exactly one place, on the target.

With closedby="any" on the dialog. The attribute decides which routes can close the dialog and has three values. any allows everything, including a click on the backdrop. closerequest allows the platform's route, meaning Escape, plus closing from code, but no click outside. none allows only closing from code or a button.

Without it, a modal dialog behaves as closerequest and a non-modal one as none. That explains why a click on the backdrop never did anything: it was never meant to. For a dialog that only informs, any is usually right. For one where someone is filling in a form, rather not, because an accidental click outside throws everything away.

Chrome and Edge have supported closedby since version 134 and Firefox since 141. According to caniuse, Safari supports it so far only in Technology Preview. The attribute is part of the dialogs and popovers focus area of Interop 2026, together with the :open pseudo-class and popover="hint".

close closes immediately, request-close asks first. With request-close the dialog fires a cancel event first, and only if nobody prevents it does closing follow with the close event. The same happens on Escape and on a click outside. request-close is the counterpart to the requestClose method in script.

That lets you handle the most common confirmation in one place: should the dialog really close while there are unsaved changes in it? A listener on cancel checks that and calls preventDefault when needed. Because Escape, click outside and the cancel button take the same route, there is one check instead of three.

For the button that confirms something, close stays right, because nothing should be asked there any more. For the one that cancels, request-close is the better choice.

For command and commandfor usually nothing any more, for closedby a few lines. The commands have run in every major engine since Safari 26.2, so a fallback is only worth it when a noticeable share of visitors uses older versions. In that case you check whether buttons know the command property, and otherwise attach a click listener that calls showModal or close.

closedby is different, because Safari does not ship it yet. The fallback is small: a click whose target is the dialog itself rather than an element inside it came from the backdrop. You then call requestClose, so the same cancel route applies as in the other browsers. It matters that the dialog itself has no padding and the content sits in an element of its own, otherwise a click on the dialog's edge also counts as a click outside.

Both checks only run when the attribute is missing. In Chrome, Edge and Firefox the markup stays the only source, and once Safari ships closedby the fallback becomes ineffective on its own.