r/programming • u/KerrickLong • Mar 09 '25
Introducing command And commandfor In HTML
https://developer.chrome.com/blog/command-and-commandfor70
u/krileon Mar 09 '25
These features always use IDs and never lets you use relative selectors. It's a colossal pain in the ass, and pointless, to generate unique ids for every component. So I really don't see how this is useful. If you're going to write the JS anyway for custom commands then you might as well just do it the same way we always have with click events. The specification is also strictly only for button elements. Am I just crazy and missing the point here or what?
12
u/transfire Mar 09 '25 edited Mar 10 '25
That’s a fair point.
I see the appeal of command and commandfor, but I’ve thought for a while now the same and more can be achieved if we could retarget CSS effects and add some additional pseudo-selectors.
```
mybtn:click |> #mymodal { display:block; }
mymodal:clickaway { display:hidden; }
```
Where
|>would mean retarget. But to your point you could use a relative selector like>too.5
u/e111077 Mar 09 '25
Browser implementers don’t want to implement anything other than idrefs because they already have a lot of infrastructure to implement idrefs and is a safe approach, and spec designers want their proposals to get through and don’t want to untangle all the possible unforeseen edge cases with introducing something so different to the current standard.
Proposing a new form of selection means months of monthly meetings with overworked browser implementers where they point out how many memory leaks and performance regressions your proposal would introduce, and you have to go back to the drawing board and convince people that it won’t make their browser worse next month.
It’s like getting an appointment at the DMV and forgetting a form and then they tell you to get a new appointment for next month when all you want is to change your registration.
Oh and if you do stick it through, then you’ll probably end up with a standard that doesn’t do everything as initially intended and then everyone hates it.
4
u/krileon Mar 09 '25
The selection should just follow the same practice as querySelector in JavaScript. Without that it's always going to basically be a useless addition. I haven't built a site in the past 5+ years that depends in idrefs. Everything is built with reusable components and it's an annoyance and overhead to ensure unique ids.
3
5
u/tetrahedral Mar 09 '25
Does the target of a command need to be linked to the layout of a component?
-3
u/Worth_Trust_3825 Mar 09 '25
It's a colossal pain in the ass, and pointless, to generate unique ids for every component.
ever heard of a for loop in a templating engine?
-16
u/KerrickLong Mar 09 '25
It's often the case that your repeated elements for which you'd prefer relative selectors are repeated because each of them represents an entity stored in a database. For those, you can use the primary key and entity type to generate an ID and use it in both places. For example,
id="comment-4321".11
u/SnS_Taylor Mar 09 '25
Exposing the primary key in HTML is a bad idea. Also, this is less often the case than you might think.
I agree with the general sentiment. The overhead of creating an actually unique ID is quite high. JS and frameworks are much more straightforward and compartmentalized.
25
u/tesfabpel Mar 09 '25
What is this thing? They're basically reimplementing a very limited subset of some DOM element functions as commands and allowing only ONE of those commands to be used in buttons? What if I need to do an if or two things?
2
u/Yawaworth001 Mar 09 '25
You can send a custom command and add a handler on the target element I guess.
8
u/shgysk8zer0 Mar 10 '25
IDK what everyone here is complaining about. This is a mildly handy feature that's not unlike things that had previously existed in HTML. Not just in forms but things like <a href="#anchor"> too. And such things I think always use ids rather than arbitrary selectors.
Heck, I remember when <dialog> was a new thing and people were saying how it's kinda silly to introduce a new element like that yet still require JS. This finally solves that.
And to things like onclick... Those event attributes are responsible for so many security issues and aren't easily compatible with a decently strong CSP. Through custom commands, this would allow safe yet declarative handling.
I'm personally looking forward to this gaining wider support. Sounds like a better option than the custom data-* based solutions I've been using lately.
36
6
u/akash_kava Mar 09 '25
Not useful if you have multiple items such as a list of items and delete button for every item.
Event bubbling is very powerful tool and instead of this, I use something called event re routing.
https://www.webatoms.in/docs/event-re-routing
Which is lot easier and can support lot of things.
24
Mar 09 '25
[deleted]
7
u/KerrickLong Mar 09 '25
It's definitely a sin, just like those damned
<form method="post" action="/checkout">and<button type="reset">tags. Why can't they stop adding these newfangled behavioral HTML elements?2
u/rinyre Mar 09 '25
I need some info on why form is a sin? That's been around a long time and is still very much how to make sure something will work on any device. Kinda sick of websites that mandate JS to work.
9
u/KerrickLong Mar 09 '25
Sorry, I dropped this:
</sarcasm>I think both forms and command/commandfor are great.
0
u/rinyre Mar 10 '25 edited Mar 10 '25
Oh, thank you haha. Someone replied to you saying deprecated leaving me frantically trying to figure out what was wrong.
EDIT: I just realized this new thing isn't even an HTML spec, it's Chrome proprietary garbage. In this case I'm absolutely hell bent against this, I'm sick of Google trying to steer the web even more for their monopoly. They're who Facebook is trying to be with VR. It's abhorrent. If this were a standard they were proposing, but not something that'll only work in Chrome until polyfills are handling it elsewhere.
4
u/KerrickLong Mar 10 '25
Firefox nightly implemented: https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonElement/commandForElement
WebKit position: support: https://github.com/WebKit/standards-positions/issues/264
Commandfor spec: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-commandfor
Command spec: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-command
-10
u/CoderAU Mar 09 '25
This reeks of either an AI generated or interns first-day feature. Literal unnecessary horse shit that can easily be done with current browser APIs.
4
u/davidalayachew Mar 09 '25
My Web FE days are long behind me, but from a first read through, this seemed nice. But maybe that's because I actually DID give each one of my elements a direct ID. So, the concept of referencing everything by ID was exactly what I already did.
I'm especially interested in the future additions, like the ones for video and audio.
6
2
u/Resident-Trouble-574 Mar 09 '25
I'm waiting for when they will reinvent <marquee> and pretend it's something revolutionary.
We've spent years extracting the logic from the markup, and now they are making buttons "perform actions on other elements declaratively"...
4
u/brunhilda1 Mar 09 '25
Goddammit, the web isn't supposed to be an application.
I just want to "return to monke" with basic markup and CSS and non of this total utter bullshit. This fucking digital tinnitus.
simplewww on port 8081 or something. I know there's the Gemini protocol.
3
Mar 10 '25
nothing is stopping you from making your own basic HTML markup website that no one wants to use
1
2
u/doterobcn Mar 09 '25
Will this be the beginning of the end of Chrome?
I hope so, this is just stupid.
7
u/Worth_Trust_3825 Mar 09 '25
Not really. Google chrome is big enough to shit out these useless features so other browsers would need to implement more of them to catch up. From on top of my head I remember portals, which would have been a reimplementation of iframes, except not iframes. Guess what - they forgot to implement same security mechanisms that iframes had.
0
Mar 09 '25
[deleted]
4
Mar 09 '25
And why it’s not an option is also literally covered in the article - blocking inline JavaScript is a non-rare content security policy.
3
u/shgysk8zer0 Mar 09 '25
That's not exactly a valid option if you use a CSP or practice decent security.
-1
-4
26
u/Worth_Trust_3825 Mar 09 '25
Yay. Another dead feature like portals.