Introducing command And commandfor In HTML

While programming language theorists have been speculating about “goto”’s more powerful cousin “comefrom” since the 80s, it was only implemented in intercal. Intercal, while clearly superior in safety, performance, and ergonomics to languages like C, has struggled to break into the commercial market (likely because worse is better). It’s exciting to see javascript integrate this feature from intercal- hopefully this leads to a surge in polite programming, analogous to how javascript’s embrace of closure based objects has driven functiOOPnal programming into the mainstream

&gt; Buttons ... provide the foundation of interactivity on the web.<p>This is a very neat way to sum up the difference between the &#x27;old&#x27; and &#x27;new&#x27; web. Because, of course, it&#x27;s the hyperlink that provides the foundation of interactivity on the web.

Invokers are not just a Chrome thing for those wondering, it&#x27;s already in Firefox nightly as well <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;HTMLButtonElement&#x2F;commandForElement" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;HTMLButtonE...</a>

The specifications<p>button element, commandfor armttribute: <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;form-elements.html#attr-button-commandfor" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;form-elements.html#at...</a><p>button element, command attribute: <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;form-elements.html#attr-button-command" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;form-elements.html#at...</a>

Is this really the action&#x2F;messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here.<p>It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I&#x27;d expect to see lots of enhanvement requests once that box was opened :)<p>There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.

&gt; the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.<p>Didn&#x27;t these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions&#x2F;attributes? Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can&#x27;t just release an update and remove stuff you (&quot;you&quot; as in: the web devs at your company that happen to be in the same company that builds a browser) don&#x27;t need any more.

I don&#x27;t know if it&#x27;s the way my brain works, or just an aesthetic thing, but I am completely allergic to programming with strings. Totally get the reasoning behind this, especially the accessibility wins, but I&#x27;m not particularly excited about using element IDs for yet another layer of web app behavior.

2025:<p>&gt; While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.<p>2033:<p>&gt; While HTML offers command and commandfor handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.

My dyslexic self got excited for command and conquer in HTML

Seems like they shouldn’t have implemented this without a full API. Instead the 5 or so commands, it looks like it’s possible to implement ALL JavaScript functionality through HTML, including high level APIs. That could be thousands of commands..

It&#x27;s good they are improving and extending HTML, but still a long way to go. The HTMX guys have a few good ideas.

Between this and other changes I worry they are just throwing more and more stuff at the wall to widen their browser moat.<p>Is command and commandfor <i>actually</i> a good idea? I understand the point of it, but it seems like yet another layer of cognitive load.<p>Instead why not just apply the same principle to CSS? If I could make a CSS selector for one element but have the result target other elements, then one could achieve the same results and more. It would require only a few more pseudo-selectors. And while it probably isn’t necessary, I think it might be prudent to mark the properties that undergo state changes. Something like:<p><pre><code> #my-popover { display:= none; } #my-button:click { |&gt; #my-popover { display:= block; } } </code></pre> Where `|&gt;` retargets and the `=` indicates the property can undergo state changes. (Maybe the syntax could be better, but you get the idea.)

So basic click events without JS.<p>Seems to only work with popups?<p>Maybe a push for Google Ads on that super tiny bit of ad market who don&#x27;t use JS

I&#x27;m wondering if these new html features will eventually get traction, anyone knows how&#x27;s the usage of latest popover and dialog elements? I&#x27;m asking because I always wondered who would ever use them as JavaScript based dialogs are so ubiquitous and they can&#x27;t easily be content blocked vs querySelectorAll(&quot;dialog&quot;) and disable them. For the sake of being semantic? But who really would write a semantic web anymore? Maybe for AI Agents? Why keep bloating the web platform?

This will be great!<p>I was just working on an app where this exact pattern would have been useful. The app mixes serverside html with some sprinkles of React for a checkout flow. Command and commandfor would have made the linking of the two much nicer. Apps following the islands pattern will also benefit from this feature.<p>Sidenote: I think the web&#x27;s biggest problem in the future will be how hard it is to deprecate functionality.<p>Maybe we need Html6 to be about removing&#x2F;simplifying features from the browsers?

One more case of Fire and Motion[0] in the industry.<p>[0] <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2002&#x2F;01&#x2F;06&#x2F;fire-and-motion&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2002&#x2F;01&#x2F;06&#x2F;fire-and-motion&#x2F;</a>

I&#x27;m curious, as a noob in web programming. That first example does<p><pre><code> document.addEventListener(&#x27;click&#x27;, ... </code></pre> Instead of<p><pre><code> someButton.addEventListener(&#x27;click&#x27;, ... </code></pre> And in fact, all the framework example show button onClick not document onClick<p>I know some situations where adding the event listener to the document is correct but I&#x27;ve never seen it in this button type situation.<p>Is that pattern for buttons common? What does it solve?

I do not understand why they did it now when JavaScript already does it. The thing just adds entropy without a clear value.

Oh, this seems like a nice generalization of the popover specific attributes. Could replace &lt;button type=&quot;submit&quot;&gt; with &lt;button command=&quot;submit&quot;&gt; and default commandfor to the ancestor form.

&gt;the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.<p>At first I was worried because they just added the popover API recently, which itself replaced &lt;dialog&gt;, but this is still using the same API, just calling it from HTML differently. Still, I&#x27;m not fully clear on what the long term goal here is? Replacing UI toolkits? Simplifying state frameworks by removing js from certain functions? For example, the play&#x2F;pause functionality.[0] For a simple website, you don&#x27;t need to add any such functionality because browsers have built in video players that allow you to play, pause, mute etc. So this isn&#x27;t necessary for simple websites. But then for websites that are more complex, you would already be using js presumably?<p>I do mostly like what is written here about the project in general, which seems to answer the above question:<p>&gt;But another 15 years have gone by since the last major revision to form and UI interfaces. Most complex web projects today need far more than what HTML5 form and UI controls provide. And so, all-too-often today’s web developers turn to heavy JavaScript frameworks to build the user interfaces their designers are asking for. These custom interfaces are rarely fully accessible. They slow down the page, consume power, open security vulnerabilities and exclude people.<p>&gt;Additionally, today’s projects often reject existing built-in form and UI controls because they require more agency over the look and feel of the interface. Web designers demand the ability to express their project’s branding across every element on the page, including all user interfaces. Current form and website-level UI controls do not allow for this.[1]<p>So the goal is to remove JS from UI components for UIs that already exist natively in HTML. Still, at least for the above video example, some sites want different behavior when the user taps on the screen. Some will bring up the video playback bar and settings, others will immediately pause, others will pause if the playback bar is hidden and remove the bar if visible, etc. I don&#x27;t see how you can do that without JS, at which point el.playing = false seems much better than using a button command attribute. Or is this just a bad example?<p>[0] linked in the article: <a href="https:&#x2F;&#x2F;open-ui.org&#x2F;components&#x2F;future-invokers.explainer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;open-ui.org&#x2F;components&#x2F;future-invokers.explainer&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;open-ui.org&#x2F;charter&#x2F;" rel="nofollow">https:&#x2F;&#x2F;open-ui.org&#x2F;charter&#x2F;</a>

We need a proper rich UI application execution environment, and if HTML, being a primarily document oriented platform can’t be retrofitted to provide that, then we need a new one

Oh, it&#x27;s coming back!<p>Called for it: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40888664">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40888664</a>

This is basically HTMX. Why don&#x27;t they just integrate it natively into the browser?

Since it&#x27;s all about buttons, it&#x27;s a shame they missed the opportunity to call it butfor.

wait, when did we get “dialog” and “popover” tags? these are wholly unfamiliar to me<p>also I sort of expected this feature to interact with CSS somehow, you could implement a lot of behavior by just adding and removing styles

everyone is crediting intercal but<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Comefrom" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Comefrom</a><p>speaks to the history and rightly credits larry clark

&lt;style&gt; #my-popover { display: none; border: 1px solid black; padding: 10px; margin-top: 10px; } #toggle:checked + #my-popover { display: block; } &lt;&#x2F;style&gt; &lt;body&gt;<p>&lt;label for=&quot;toggle&quot; id=&quot;my-button&quot;&gt;Toggle Popover&lt;&#x2F;label&gt; &lt;input type=&quot;checkbox&quot; id=&quot;toggle&quot; style=&quot;display: none;&quot;&gt; &lt;div id=&quot;my-popover&quot;&gt;My content!&lt;&#x2F;div&gt;<p>&lt;&#x2F;body&gt; Wont this work a toggle popup with html+css only no js yet interactive with label

I&#x27;ve misread this excitedly as &quot;Command and Conquer&quot; for HTML thinking it had to do with the recently released source code.

Would make interaction easier for ai agents on the web.

HTML needs a &lt;button type=&quot;revolt&quot;&#x2F;&gt; to counteract the &lt;button type=&quot;submit&quot;&#x2F;&gt;.

Interestingly the examples don’t show interaction with &lt;form&gt;. In the deletion confirm example, can I put this inside a form and have it continue to POST when confirmed and cancelled when cancel is hit in the popover?<p>If I still need js to then submit the form it feels like this falls quite a bit short.

I am waiting for the author of HTMX&#x27;s opinion on it. They dont seems to have commented here yet.

That looks like more XSS vectors.<p>Also what do I do if I want to fire analytics even and open the modal. Correct, use onClick.

HTML seems to incubate some htmx things

Someone was just telling me that Google doesn&#x27;t have significant influence on web standards.

&gt; While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.<p>What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?

The author is <i>not</i> affiliated with Google. Is this from &quot;external&quot; contributors? If such a thing called open-source is still happening here, I would send all of my respect to you the people who do it for the Web.

Very good innovation - to eliminate all standard boilerplate javascript and code it into the HTML in declarative manner.<p>Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code

Is there an RFC for this?

&gt; While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.<p>WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can&#x27;t believe what I&#x27;m reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?

&gt;&gt; show-popover: Maps to el.showPopover().<p>I&#x27;m surprised they&#x27;re still keeping this convention of kabob-to-camelCase function name transcribing. I&#x27;ve never been a fan.

The direction of web standards is problematic. Getting overengineered. CSP is retarded. Trying to prevent all possible security vulnerabilities by removing functionality is just dumb and an impossible task. It&#x27;s just converting a simple vulnerability into a complex vulnerability. Things are headed in a bad direction. Throwing the baby out with the bathwater... To remove all possible vulnerabilities means removing all possible features. Web programming will become a useless bureaucratic mess if we continue down this path.

more builtin behavior, less JS to ship. pretty dope

I like how they present it as a novel idea, when this is as old as it gets. This is not new of course but it seems it won´t stop. Ever.

Browsers: We are not happy that only Tailwind will pollute HTML. We want our part of cake too.

when are you guys at chrome planning to add a virtual scroller or virtual list or virtual table. pretty sure every infinite scrolling pattern out there could use a component like this

am I the only one annoyed by the fact that they do not have syntax highlighting on most of their code examples?

It&#x27;s been some years since I coded any front-end HTML. Sure looks like it&#x27;s gotten messy.

I&#x27;d gladly give up this if I could get ublock origin and other pre v3 extensions back

Thanks for sharing<p>The idea of declarative UI actions without JS is appealing<p>The good:<p>* Killing boilerplate for popovers&#x2F;modals (no more aria-expanded juggling).<p>* Built-in commands like show-modal bake accessibility into markup.<p>* Custom commands (e.g., --rotate-landscape) let components expose APIs via HTML.<p>My doubts:<p>* Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist?<p>* Shadow DOM friction: Needing JS to set .commandForElement across shadow roots feels like a half-solved problem.<p>* Future-proofing: If OpenUI adds 20+ commands (e.g., show-picker, toggle-details), will this bloat the platform with niche syntax?

Random aside. Their code snippet has this comment:<p><pre><code> &#x2F;&#x2F; popovers have light dismiss which influences our state </code></pre> And I hadn&#x27;t heard of that phrase before! Turns out it means &quot;clicking elsewhere closes the thing:&quot;<p>&gt; <i>&quot;Light dismiss&quot; means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.</i>[0]<p>Like what, say, a `&lt;select&gt;` does when open.<p>Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was &quot;light&quot; as in &quot;light DOM,&quot; but I guess it&#x27;s &quot;light&quot; as an antonym of &quot;explicit?&quot; Looks like there was some back and forth on this, and it was even proposed as an attribute: <a href="https:&#x2F;&#x2F;github.com&#x2F;openui&#x2F;open-ui&#x2F;issues&#x2F;834">https:&#x2F;&#x2F;github.com&#x2F;openui&#x2F;open-ui&#x2F;issues&#x2F;834</a><p>[0] <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;popover.html#popover-light-dismiss" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;popover.html#popover-...</a>

It’s just like the target &#x2F; selector pattern from NeXT AppKit over thirty years ago… Except that the syntax is clunkier and less type-safe than what they did using 1994 Objective-C.<p>It’s not exaggeration to say that the web has set UIs back by decades.<p>The other day I was trying to make editable table cells in a leading “enterprise-grade” React component framework. It required several screenfuls of obscure and brittle code. The same operation used to require implementing a single delegate method in 1990s AppKit.

Is that a proprietary HTML extension?<p>Are we back to the IE-era mess then?<p>If so, let&#x27;s bring &lt;marquee&gt; back.

Next thing we’ll get DOM events <i>beforecommand</i> and <i>aftercommand</i>. &#x2F;s<p>In principle this declarative approach goes in the right direction, but without an overarching concept and vision of the web UI of the future, this feels like adding just another wrinkle to the stack.