Should You Use Invoker Commands on Marketing Sites Yet?

Are invoker commands ready to use on a client site?

As of September 2026, yes for progressive enhancement and not yet as your only mechanism. MDN lists the Invoker Commands API as Baseline 2025 newly available, working across the latest browser versions since December 2025. That is roughly ten months of interoperability, which is enough to build with and not enough to depend on.

This is one of the more useful additions to HTML in years, and it is quietly aimed at the exact thing marketing sites overbuild: a button that opens a thing. Modals, popovers, dropdown panels. Work that has always cost a JavaScript file.

Here is what the feature does, what the Baseline label actually promises, and how we are using it now.

What are invoker commands?

Two HTML attributes that let a button control another element without any script. MDN describes the API as providing "a way to declaratively assign behaviors to buttons, allowing control of interactive elements when the button is enacted".

The first attribute is commandfor. MDN says it "turns a button element into a command invoker, controlling the given interactive element", and it takes the ID of the target element as its value. The second is command, which "specifies the action to be performed on an element being controlled by a control button".

So a button carries two attributes: which element it targets, and what to do to it. That is the entire mental model. No listener, no query selector, no state variable.

What can they do with no JavaScript at all?

The built-in commands cover the patterns that make up most of this work. MDN documents show-modal and close for dialogs, and toggle-popover, show-popover and hide-popover for popovers.

Put those next to a real page and the coverage is better than it sounds. A cookie notice, a video lightbox, a mobile navigation panel, a pricing comparison overlay, a "contact us" modal. All of those are one element plus one button with two attributes.

MDN is direct about why this is worth caring about: declaring the behaviour "can be advantageous as users do not have to wait for JavaScript to download and execute to make these buttons interactive". The button works from the first paint.

What does Baseline 2025 newly available actually promise?

Interoperability today, not safety everywhere. Baseline's own definition of newly available is that "the feature is supported by all of the core browsers, and is therefore interoperable". The core browser set is Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS.

The second stage is the one teams actually want. Baseline says a feature becomes widely available when "30 months have passed since the newly interoperable date", at which point it "can be used by most sites without worrying about support".

Do the arithmetic and invoker commands, interoperable since December 2025, would reach widely available around the middle of 2028. That is the honest read: current browsers all support it, and a meaningful slice of real visitors are not on current browsers. We use the same reasoning on every new platform feature, which we set out in how to read Baseline before you ship.

How does this compare to the popover attribute?

Popover arrived first and is the more settled of the two. MDN lists the Popover API as Baseline 2025 newly available since January 2025, eleven months ahead of invoker commands. On the same 30 month rule, that puts it at widely available around mid 2027.

The two are complementary rather than competing. The popover attribute turns an element into a popover and takes a state of auto, hint or manual. The popovertarget attribute "turns a button or input element into a popover control button", taking the ID of the popover it controls.

So popover already gave you a declarative button for popovers specifically. Invoker commands generalise the idea: one attribute pair that also drives dialogs, and that is extensible to anything. If you already use popover, the mental model transfers directly. We wrote it up in our guide to the Popover API.

Why does removing the event listener matter so much?

Because the listener is never the only cost. It arrives with a bundle, a framework to mount it, a hydration step and a race condition where the button is visible before it works.

That last one is the failure we see most on marketing sites. A visitor on a slow connection taps the menu button, nothing happens, they tap again, and by the time the script lands they have opened and closed it. The button looked ready and was not.

Declarative attributes remove that state entirely. The browser knows what the button does before any script runs, so there is no window where the interface is a lie. That is a real accessibility and performance win, not a code-style preference.

What about custom commands?

They exist, and they are the part that makes this an API rather than a shortcut. MDN documents custom command names prefixed with two hyphens, which fire a command event on the target element rather than performing a built-in action.

The event object is a CommandEvent, which MDN describes as representing "an event notifying the user that a command has been issued". You listen on the target element, read the command name from the event, and act. MDN's own example rotates an image using two custom commands.

This is a nicer shape than the usual click handler, because the relationship between the button and what it controls lives in the HTML where a reader can see it. The script only holds the behaviour, not the wiring.

What should you still write JavaScript for?

Anything with state, anything with data, anything conditional. A button that submits a form and shows a result. A panel whose contents depend on what the visitor selected. Validation. Analytics.

Invoker commands replace one narrow job: connecting a button to an element and naming an action. That job happens to be extremely common, which is why the feature is valuable, but it is not a general replacement for scripting.

The rule we use is that if the answer to "what does this button do" fits in one of the built-in command names, use the attribute. If it needs a sentence, write the code.

How would we roll this out on a client site today?

As an enhancement, with the old path intact. The dialog element and the button both work without the command attribute, so a browser that does not recognise the attributes gets a button that does nothing unless a fallback exists.

So our approach is to keep a small script that binds the same behaviour, and let the declarative path win where it is supported. The script is tiny, it loads late, and it is deletable in a year or two when the Baseline status moves. Nobody has to make a bet.

That is the ordinary shape of shipping new platform features responsibly, and it is the same reasoning behind everything in our take on progressive enhancement.

Where is declarative HTML heading?

Toward taking back the interactions that JavaScript borrowed. Dialogs, popovers, and now a generic button-to-element command mechanism. The direction is consistent: patterns that every site rebuilds get absorbed into the platform, and the platform version is faster and more accessible than the version we each wrote.

Our expectation is that in two years a marketing site with no JavaScript at all will handle navigation panels, modals and disclosure widgets natively, and that will read as normal rather than clever. The teams that benefit first are the ones already writing HTML that could accept these attributes without a rewrite.

If you want a view on which of these features your site could adopt now and which are worth waiting on, we are happy to go through it with you at phoenix.studio.