Introducing command And commandfor In HTML

Original Article ↗ Hacker News Discussion ↗

Standards, browsers, and process

  • Initial concern that this might be a Chrome‑only/proprietary feature; others point out it’s in the WHATWG spec, has been discussed in OpenUI, and is already in Firefox Nightly and behind flags in Safari.
  • Some see this as “Chrome is the new IE” and worry about Google’s outsized influence; others note that HTML has long evolved via “ship first, spec later” across all browser vendors.
  • There’s mild frustration that popover-specific attributes were introduced recently and are now being “replaced,” raising concerns about web features being deprecated quickly despite the web’s long-term compatibility expectations.

What command / commandfor bring

  • Declarative wiring between a trigger element (typically a button) and a target element, replacing boilerplate JS like addEventListener + showPopover() + ARIA updates.
  • Viewed as a generalization of the popover attributes, and as a way to put more interaction “in HTML instead of JS,” similar in spirit to HTMX.
  • Supporters highlight:
    • Less boilerplate and fewer bugs for popovers, dialogs, and other basic UI.
    • Better baked-in accessibility (e.g., ARIA state handled by the platform).
    • Good fit for “islands”/mixed server-rendered + light JS architectures.
    • Easier interaction for screen readers and potential AI agents.

Limits, coexistence with JS, and complexity

  • Many doubt this removes the need for JS in any non-trivial UI; they see it more as a convenience or incremental enhancement than a full alternative.
  • Some worry HTML is becoming a pseudo-programming language, duplicating JS capabilities and echoing the history of “declarative systems that slowly turn imperative.”
  • Others argue it improves locality of behavior: you can inspect a button and immediately see what it will do.

Security, CSP, and XSS

  • A key motivation mentioned is CSP: onclick is effectively eval and often blocked, whereas command/commandfor are limited, non-arbitrary actions.
  • One commenter fears new XSS vectors via HTML injection; others counter that these attributes don’t execute arbitrary JS, though untrusted content should still be filtered.

Relation to HTMX and older UI patterns

  • Multiple people note the similarity to HTMX-style declarative interaction; some predict the platform will eventually converge on an HTMX-like model.
  • Others see echoes of NeXT/AppKit’s target–action, and more broadly of long-standing UI message/command patterns; opinions differ on whether the web is “catching up” or reinventing a worse version.

Broader concerns about web direction

  • Significant thread arguing the platform is over-engineered and constantly expanding, making independent browsers harder to build and maintain.
  • Counterpoint: richer built-ins (like this) can reduce JS bloat, improve accessibility, and move some complexity out of fragile app code into the browser, even if it adds surface area to HTML.