22 ms·

Introducing command And commandfor In HTML

431 points by Kerrick 2y ago

deleted 2y ago
[deleted]
alterom 2y ago
Is that a proprietary HTML extension? Are we back to the IE-era mess then? If so, let's bring <marquee> back.
- Frederation 2y ago
  Man, that brought back memories.
- finnthehuman 2y ago
  >Is that a proprietary HTML extension? No, of course not. Web standards are whatever google decides they are.
- shermantanktop 2y ago
  Have you been following how HTML has evolved over the past 20 years? Your comment suggests not. It’s not entirely a standards-driven process. It’s common for browser vendors to just build stuff. That’s been a mixed blessing but it has definitely been faster than some W3C consortium debating “ergonomics” for years. Successful additions get backported into the spec, slowly.
  - deleted 2y ago
    [deleted]
- jdiff 2y ago
  Doesn't appear to be. https://github.com/whatwg/html/pull/9841 https://github.com/whatwg/html/pull/9841 https://github.com/whatwg/html/issues/9625 https://github.com/whatwg/html/issues/9625 Seems to have been in the works since 2023, out in the open, with support from all major browser engines.
- anamexis 2y ago
  TFA links to the spec - https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-command https://html.spec.whatwg.org/multipage/form-elements.html#at... It's in Firefox and Safari
- deleted 2y ago
  [deleted]
- hennell 2y ago
  Marquee still works, we just don't tell marketing. https://caniuse.com/mdn-html_elements_marquee https://caniuse.com/mdn-html_elements_marquee
- slt2021 2y ago
  Chrome is the new IE. Whatever google decides will become a standard (both defacto due to them controlling the market and just shipping new version just in time and de-jure due to them financing W3C consortium and other standard bodies)
ykrishnan 2y ago
Is there an RFC for this?
- teh_klev 2y ago
  Start here I think: https://github.com/WebKit/standards-positions/issues/264 https://github.com/WebKit/standards-positions/issues/264
jt2190 2y ago
The specifications button element, commandfor armttribute: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-commandfor https://html.spec.whatwg.org/multipage/form-elements.html#at... button element, command attribute: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-command https://html.spec.whatwg.org/multipage/form-elements.html#at...
msub2 2y ago
Invokers are not just a Chrome thing for those wondering, it's already in Firefox nightly as well https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonElement/commandForElement https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonE...
- Kerrick 2y ago
  WebKit has taken a "support" position. https://github.com/WebKit/standards-positions/issues/264 https://github.com/WebKit/standards-positions/issues/264
- deleted 2y ago
  [deleted]
QuadmasterXLII 2y ago
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
- alterom 2y ago
  >hopefully this leads to a surge in polite programming But not too polite. The compiler wouldn't like that.
  - SAI_Peregrinus 2y ago
    Of course not. Sycophantic code is quite grating.
    - fuzztester 2y ago
      what's the download site for the psycho-fantic language? gimme! puhleeze.
  - esafak 2y ago
    Demure is the fashion these days, I'm told.
    - mock-possum 2y ago
      Very.
    - BobbyTables2 2y ago
      Spoken like a bussin’ sigma that eats - no cap.
darth_avocado 2y ago
My dyslexic self got excited for command and conquer in HTML
- netghost 2y ago
  I definitely read about buttons waiting to see how this would unlock the ability to transpile Command and Conquer in some novel way. Still appreciate the new features though.
- k6hkUZtLUM 2y ago
  Me too. I was reading about buttons ... and wondering where was the game? Although, the buttons are very interesting.
- DeathRay2K 2y ago
  Just today I discovered there’s a Red Alert port to Three.js in the works: https://github.com/chongdashu/CnC_Red_Alert-ThreeJs https://github.com/chongdashu/CnC_Red_Alert-ThreeJs
TIPSIO 2y ago
So basic click events without JS. Seems to only work with popups? Maybe a push for Google Ads on that super tiny bit of ad market who don't use JS
error9348 2y ago
Would make interaction easier for ai agents on the web.
- badc0ffee 2y ago
  And screen readers.
vFunct 2y ago
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..
- ericyd 2y ago
  This is my thought too, I'm having trouble envisioning a case where a reasonably complex UI wouldn't still need JS. I guess it provides a roadmap to incremental adoption.
- Someone1234 2y ago
  The real power is custom commands and a standard way to implement them. The built-in commands will always be just conveniences that many convert to a custom version as complexity increases. Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
- PokestarFan 2y ago
  I don't see how it should be too hard to implement, you could abstractly have a system where the command string is translated as such: 1. Split the string by dashes into an array 2. Make the first character of the first array item lowercase, make the first character of the rest uppercase 3. Concatenate the pieces together 4. Do `document.getElementById(element.commandfor)[concatenated]()` Obviously this doesn't have the myriad number of checks to make sure that the element exists, the method exists, the method takes no parameters, etc. This would also allow custom commands easily, since you could do `document.getElementById(element.commandfor).myCustomMethod = function() { /* ... */ }`
  - rafram 2y ago
    Given that this is meant to be a safe alternative to inline JS, executing arbitrary JS would be counterproductive.
gatinsama 2y ago
It's good they are improving and extending HTML, but still a long way to go. The HTMX guys have a few good ideas.
- rsync 2y ago
  No, it is terrible that "they" continue to extend and "improve" HTML. This is the reason it seems impossible for an independent web browser to be created and maintained: because what should be a simple and predictable spec over the last twenty years is a rapidly moving target that takes significant resources just to track. We could have ten different open-source web browsers (like Konqueror) if we weren't cramming the HTML spec full of bloat that nobody wants and that we all install extensions to disable anyway ...
  - wruza 2y ago
    I’m pretty sure this is the only goal. Everyone with a neuron or two can see that the internet doesn’t use web tech and abstracts it away as soon as possible. These people just grow their corporate security by adding nonsensical bullshit that makes zero difference irl.
  - wmanley 2y ago
    > We could have ten different open-source web browsers To what end?
    - hollowturtle 2y ago
      Sane competition, developers and end users would benefit from competition. This is just corporate lock-in. When a user is required to install Chrome for using a web app we're failing him as a platform, and the open web goes off the rail
    - johnfernow 2y ago
      Having a browser written entirely (or mostly) in a memory safe language. LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking. Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking. In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS. Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features. As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.
hoc 2y ago
Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here. 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'd expect to see lots of enhanvement requests once that box was opened :) There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
- dartos 2y ago
  It’s not that the idea is brand new, just that it’s now implemented in chrome and in the web specs.
- wruza 2y ago
  You thought web was 15 years behind, but it quickly catches up to 30 years old tech! News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
  - 9dev 2y ago
    What would have been something useful?
Starlord2048 2y ago
Thanks for sharing The idea of declarative UI actions without JS is appealing The good: * Killing boilerplate for popovers/modals (no more aria-expanded juggling). * Built-in commands like show-modal bake accessibility into markup. * Custom commands (e.g., --rotate-landscape) let components expose APIs via HTML. My doubts: * Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist? * Shadow DOM friction: Needing JS to set .commandForElement across shadow roots feels like a half-solved problem. * Future-proofing: If OpenUI adds 20+ commands (e.g., show-picker, toggle-details), will this bloat the platform with niche syntax?
- SamBam 2y ago
  > Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist? The same way React or other frameworks can hook into things like CSS animations. If CSS animations didn't exist, the JS framework would have to write all the code themselves. With them existing, they can just set the properties and have it work. Even if you're writing a basic menu popup directly in React, having these properties to use directly in your JSX means less code and less room for error. Then if you need to do something special, you may need to do it by hand and not use these properties, just like if you needed a special animation you might have to do it without using the CSS animation properties.
  - fitsumbelay 2y ago
    agreed, my sense is that frameworks will update to take advantage as they've done in the past
- toomim 2y ago
  > Is this just shifting complexity from JS to HTML? Very well said. This is the problem. There's an old adage that every "scripting" language starts out small, but then ultimately needs all the features of a full programming language. If we start putting programming features into HTML, we'll eventually turn it into a full turing-complete programming language, with loops, conditionals, variables, and function calls. We'll have recreated javascript, outside of javascript.
cratermoon 2y ago
I'd gladly give up this if I could get ublock origin and other pre v3 extensions back
ulrischa 2y ago
HTML seems to incubate some htmx things
lelandfe 2y ago
Random aside. Their code snippet has this comment: // popovers have light dismiss which influences our state And I hadn't heard of that phrase before! Turns out it means "clicking elsewhere closes the thing:" > "Light dismiss" means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.[0] Like what, say, a `<select>` does when open. Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was "light" as in "light DOM," but I guess it's "light" as an antonym of "explicit?" Looks like there was some back and forth on this, and it was even proposed as an attribute: https://github.com/openui/open-ui/issues/834 https://github.com/openui/open-ui/issues/834 [0] https://html.spec.whatwg.org/multipage/popover.html#popover-light-dismiss https://html.spec.whatwg.org/multipage/popover.html#popover-...
- Izkata 2y ago
  I think "light" is used as in "light touch" (soft touch), something that includes brushing against a surface by accident.
  - efortis 2y ago
    I’d guess it stands for highlight. For example a modal is often highlighted by dimming and blurring the background.
- david422 2y ago
  Also random aside. I dislike this pattern for modal dialogs. Often times I will need to gather information from somewhere else, and in the process of attempting to get focus back to the dialog I've touched/tapped/clicked on something that dismisses the dialog. Very annoying.
  - victorbjorklund 2y ago
    Most of the times that would be better solved with not using a modal.
  - dylan-m 2y ago
prmph 2y ago
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
- skydhash 2y ago
  Flash? Silverlight? Swing?
  - prmph 2y ago
    I see you are skeptical, but the failure of those technologies does not mean a new HTML-like platform cannot succeed. We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.
- nullpoint420 2y ago
  +1. The Web Platform is this interesting blend between declarative and imperative, but with the benefits of neither. IMO, the web platform needs a retained mode UI model like Qt Widgets, AppKit, or UIKit. Then desktop-like applications like Figma wouldn't need to compile to WASM and render WebGL for their UI. They could just treat <divs> as views or layers.
- satvikpendem 2y ago
  Ian Hickson, who authored the HTML5 spec and leads Flutter, has written about exactly this, Towards a Modern Web Stack [0][1], to create a new stack that can handle modern web applications. Flutter is a part of it but he talks about a more general (and generalizable) stack. He's on the HN thread as well expanding on the rationale behind it. Interestingly, it seems like specific people on HN don't exactly like it, a bit funny to witness their crash outs. [0] https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 [1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/preview?pli=1&resourcekey=0-bPajpoo9IBZpG__-uCBE6w&tab=t.0 https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... (actual doc to read)
  - 2y ago
SoftTalker 2y ago
It's been some years since I coded any front-end HTML. Sure looks like it's gotten messy.
flowerthoughts 2y ago
Oh, this seems like a nice generalization of the popover specific attributes. Could replace <button type="submit"> with <button command="submit"> and default commandfor to the ancestor form.
- _betty_ 2y ago
  interesting, they could finally deprecate the form attribute on buttons...
fitsumbelay 2y ago
more builtin behavior, less JS to ship. pretty dope
fngjdflmdflg 2y ago
>the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes. At first I was worried because they just added the popover API recently, which itself replaced <dialog>, but this is still using the same API, just calling it from HTML differently. Still, I'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/pause functionality.[0] For a simple website, you don'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't necessary for simple websites. But then for websites that are more complex, you would already be using js presumably? I do mostly like what is written here about the project in general, which seems to answer the above question: >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. >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] 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'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? [0] linked in the article: https://open-ui.org/components/future-invokers.explainer/ https://open-ui.org/components/future-invokers.explainer/ [1] https://open-ui.org/charter/ https://open-ui.org/charter/
- werdnapk 2y ago
  The popover API is not a replacement for <dialog>. It's an alternative to some dialog like functionality if the use case is right.
slt2021 2y ago
Very good innovation - to eliminate all standard boilerplate javascript and code it into the HTML in declarative manner. Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code
- naikrovek 2y ago
  it looks clean, now. web devs will get ahold of this and demand that they have the ability to change the size, the animations of appearance and disappearance, specify a sound that plays when the menu is opened or closed, etc. I'm saying that this, like all other web things, will be bastardized and mutilated until it is just as complex and unworkable as the existing solutions which this is intended to replace.
  - slt2021 2y ago
    I am fine if structural stuff can be coded in HTML, while animations and bells and whistles will still have to be JS/CSS based
Tarucho 2y ago
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.
karol 2y ago
That looks like more XSS vectors. Also what do I do if I want to fire analytics even and open the modal. Correct, use onClick.
- kflgkans 2y ago
  > That looks like more XSS vectors. Could you elaborate on that? I don't understand how this leads to more XSS vectors.
  - karol 2y ago
    If these are proposals to use bindings between html attributes and calling JS methods, then it's enough to inject HTML, not JS, to start executing JS.
    - Keithamus 2y ago
      It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
nikeee 2y ago
> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes. Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/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't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
- deleted 2y ago
  [deleted]
- mubou 2y ago
  I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.
pavlov 2y ago
It’s just like the target / 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. It’s not exaggeration to say that the web has set UIs back by decades. 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.
- naasking 2y ago
  > It required several screenfuls of obscure and brittle code I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.
- gear54rus 2y ago
  > set UIs back Oh that's why 90% of online interactions are now on the web now ... stupid me thinking because it's a superior solution. And before you say '90% are actually on mobile', well mobile doesn't use shit from 1994 also. Wonder why.
  - pavlov 2y ago
    Mobile absolutely uses “shit from 1994”. The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
    - mattl 2y ago
      Yep. All of the main 5 operating systems for consumers are from the late 80s and early 90s. - Windows 11 is Windows NT - macOS is NeXTSTEP/OPENSTEP - Linux is a free Unix like from the era where that was a new thing with both BSD and GNU working on it - Android is Linux + Java (inspired by OpenStep) - iOS/iPadOS is NeXTSTEP/OPENSTEP for phones. (OPENSTEP is an OS. OpenStep is a framework)
  - deleted 2y ago
    [deleted]
roon_shady 2y ago
am I the only one annoyed by the fact that they do not have syntax highlighting on most of their code examples?
garganzol 2y ago
I do not understand why they did it now when JavaScript already does it. The thing just adds entropy without a clear value.
webnoob 2y ago
I'm curious, as a noob in web programming. That first example does document.addEventListener('click', ... Instead of someButton.addEventListener('click', ... And in fact, all the framework example show button onClick not document onClick I know some situations where adding the event listener to the document is correct but I've never seen it in this button type situation. Is that pattern for buttons common? What does it solve?
- zerocrates 2y ago
  Generally you do it the "document" way (often called a "delegated" listener) when you have lots of elements you want to listen to, or particularly elements that will be dynamically added and removed. If you listen directly to every target element, you have to find the elements and loop through them all, they have to exist at the time you set the listener, and you have to make sure to add the listener every time you add a new element that has the same behavior. If you listen at the document (or some appropriate parent element) and then check if the element that fired the event matches what you're trying to handle, you can have one listener that will apply to all the matching children regardless of where/when/how they're added.
- irjoe 2y ago
  Using document.addEventListener means it will work even if the DOM is updated without having to add new event listeners. If I'm not expecting the DOM to change I would be more inclined to do something like: document.querySelectorAll('.menu-wrapper')).forEach(menuWrapper => { const button = menuWrapper.querySelector('.menu-opener'); const content = menuWrapper.querySelector('.menu-content'); if (!content || !button) { return; } button.addEventListener(() => { button.setAttribute('aria-expanded', 'true'); menu.showPopover(); }); content.addEventListener('toggle', e => { // reset back to aria-expanded=false on close if (e.newState == 'closed') { button.setAttribute('aria-expanded', 'false'); } }); }); The React example seems a little odd as well, if the "open" callback actually called "showPopover()" instead of only calling "setIsOpen" then the "useEffect" could be entirely redundant. The resulting code would be a lot clearer imo.
  - 2y ago
luismedel 2y ago
One more case of Fire and Motion[0] in the industry. [0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
jandrese 2y ago
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?
- jameshart 2y ago
  The reason onclick is disallowed is because it permits full JavaScript execution. An onlick attribute is ‘eval’d on click. If you can inject one into a page you get JavaScript execution. Hence, content security blocking - a rule served up on the page saying ‘nothing in this page is supposed to have onclick attributes. If you see one ignore it’. These command attributes are not arbitrary JavaScript hooks. They tell inbuilt components to do inbuilt things. It doesn’t make sense for a content security policy to say ‘nothing on this page has commands, if you see something that does ignore it’, any more than it would make sense for a content security policy to say ‘nothing in this page is in bold, if you see something that says it wants to be displayed in bold ignore it’.
  - crabmusket 2y ago
    This makes sense, but it feels like the case is overstated... Is it really common for sites to disable their own onclick attributes? Is it just the case that the CSP rule disables onclick in the HTML, but first party scripts can then attach event handlers separately?
    - jameshart 2y ago
      If you’re dynamically generating the HTML it’s safest to set the CSP to disable all inline scripts; you can permit only static scripts served from known good locations with valid sub resource integrity hashes.
  - jandrese 2y ago
    Is it common that the HTML gets injected but inline scripts can not be injected at the same time?
mpalmer 2y ago
I don't know if it'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'm not particularly excited about using element IDs for yet another layer of web app behavior.
- hdjrudni 2y ago
  I don't like it either, but at least we can pave over it with a framework, unless you're allergic to those. It makes a good building block.
  - mpalmer 2y ago
    True, and don't get me wrong, I think events are great and this will be a decent simplification, even with existing frameworks. If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.
- conartist6 2y ago
  I know what you mean
- qwery 2y ago
  Stringy code is my go-to example of a code smell. You can do it, it works and yes, as long as you write it correctly it will work correctly, but you're just kicking the can down the road, at best. HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired. It's a hack. This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
- ximm 2y ago
  I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.
CodeCompost 2y ago
This is basically HTMX. Why don't they just integrate it natively into the browser?
jl6 2y ago
Since it's all about buttons, it's a shame they missed the opportunity to call it butfor.
- smitelli 2y ago
  Sigh. Fine, I'll do it. What's a butfor?
adamredwoods 2y ago
>> show-popover: Maps to el.showPopover(). I'm surprised they're still keeping this convention of kabob-to-camelCase function name transcribing. I've never been a fan.
- stevenpetryk 2y ago
  I’d much prefer el[‘show-popover’]()
cariaso 2y ago
everyone is crediting intercal but https://en.wikipedia.org/wiki/Comefrom https://en.wikipedia.org/wiki/Comefrom speaks to the history and rightly credits larry clark
layer8 2y ago
Next thing we’ll get DOM events beforecommand and aftercommand. /s 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.
jongjong 2y ago
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can't believe what I'm reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?
- chuckadams 2y ago
  > What is the actual problem with onclick attribute? It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable? The alternative to on* attributes is addEventListener, which has also been a thing for decades.
  - e12e 2y ago
    Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
  - jongjong 2y ago
    Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused. With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data! I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
Inviz 2y ago
Oh, it's coming back! Called for it: https://news.ycombinator.com/item?id=40888664 https://news.ycombinator.com/item?id=40888664
jongjong 2y ago
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'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.
DonHopkins 2y ago
HTML needs a <button type="revolt"/> to counteract the <button type="submit"/>.
jes5199 2y ago
wait, when did we get “dialog” and “popover” tags? these are wholly unfamiliar to me 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
- tln 2y ago
  <dialog> Chrome 37, Aug 2014 Safari 15.4, Mar 2022 popover attribute Chrome 114, May 2023 Safari 17, Sep 2023
  - Zardoz84 2y ago
    Don't forget Firefox... There are some people that keeps trying to support anything that isn't f* controlled by Google or Apple. Dialog in Firefox 98 , 2022-03-08 Also, using a poly fill works even on IE 12 popover in Firefox 125, 2024-04-16
qwery 2y ago
> Buttons ... provide the foundation of interactivity on the web. This is a very neat way to sum up the difference between the 'old' and 'new' web. Because, of course, it's the hyperlink that provides the foundation of interactivity on the web.
- afavour 2y ago
  I like that but I’m not so sure. Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
  - porridgeraisin 2y ago
    Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course) For example, sorting a table could be achieved by having the column headers be a link to the same url with ?sort_by={colname} And then the server sees that and sorts and returns. Same with "dynamic" number of input fields. When the add field link is clicked you reload with ?num_fields=2
    - afavour 2y ago
      To me that feels like a technicality. It’s the same experience you’d get with a button + JS except with more latency.
      - deleted 2y ago
        [deleted]
    - furyofantares 2y ago
      Yeah but that was also implemented as a button, right? input type="submit" would display a button in 1993 AFAIK. No javascript and acted like a hyperlink - but still a button.
      - 2y ago
vivzkestrel 2y ago
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
flakiness 2y ago
The author is not affiliated with Google. Is this from "external" 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.
- Keithamus 2y ago
  Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!
transfire 2y ago
Between this and other changes I worry they are just throwing more and more stuff at the wall to widen their browser moat. Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load. 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: #my-popover { display:= none; } #my-button:click { |> #my-popover { display:= block; } } Where `|>` retargets and the `=` indicates the property can undergo state changes. (Maybe the syntax could be better, but you get the idea.)
MacGyver101 2y ago
Browsers: We are not happy that only Tailwind will pollute HTML. We want our part of cake too.
hollowturtle 2y ago
I'm wondering if these new html features will eventually get traction, anyone knows how's the usage of latest popover and dialog elements? I'm asking because I always wondered who would ever use them as JavaScript based dialogs are so ubiquitous and they can't easily be content blocked vs querySelectorAll("dialog") 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?
- garganzol 2y ago
  Google being Google, they may do it just for the sake of squeezing revenue from less likely blockable ad popups. This explains why they decided to work on HTML dialogs out of the blue. In their mind, dialog is popup, and an ad popup that you cannot block equals more money for them. Probably they are creating an area in specification for them to exploit in the future. In a twisted way of course, via extension manifest V4 or something like that.
  - hollowturtle 2y ago
    I think you're confusing some stuff. A native dialog element as a popup is easier to block, for example, you just have to select all dialog elements by tag name and convert them to div inlined elements or something like that. Can't do the same reliably when the dialog is created by a javascript library using a div that uses a random id or generated class name
- micromodel 2y ago
  I don't know who else is doing it but my team and I always use semantic HTML, including dialog elements It is, unfortunately, the least I can do to respect the user, since I have no control over the decision to load horrible tracking scripts onto their browser.
  - RobMurray 2y ago
    I really wish everyone would use semantic HTML wherever possible. The gains for accessibility are huge. Take a JS dialog or pop-up menu, for example. You would think it would be easy for everyone to use, but a screen reader user might not even be aware that it’s there in the first place. Even when they do, they still need to find it in a linear and possibly very cluttered representation of the page. It could be right next to the "open menu" button, at the bottom of the page, or somewhere else entirely. The menu/dialog could also disappear as soon as they move the focus in an attempt to find it! These are all things I put up with regularly. I think anything that makes accessibility easier for developers is a good thing, especially if it just works without having to think about accessibility.
TaurenHunter 2y ago
I've misread this excitedly as "Command and Conquer" for HTML thinking it had to do with the recently released source code.
tinodb 2y ago
Interestingly the examples don’t show interaction with <form>. 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? If I still need js to then submit the form it feels like this falls quite a bit short.
neuroelectron 2y ago
Someone was just telling me that Google doesn't have significant influence on web standards.
G_o_D 2y ago
<style> #my-popover { display: none; border: 1px solid black; padding: 10px; margin-top: 10px; } #toggle:checked + #my-popover { display: block; } </style> <body> <label for="toggle" id="my-button">Toggle Popover</label> <input type="checkbox" id="toggle" style="display: none;"> <div id="my-popover">My content!</div> </body> Wont this work a toggle popup with html+css only no js yet interactive with label
- 77 2y ago
  This hack has terrible accessibility. For one, the <label> is not focusable by default, so keyboard users won't be able to toggle the popup at all. And I don't think it's possible to dynamically set ARIA attributes without JS.
tarjei_huse 2y ago
This will be great! 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. Sidenote: I think the web's biggest problem in the future will be how hard it is to deprecate functionality. Maybe we need Html6 to be about removing/simplifying features from the browsers?
tonetheman 2y ago
[dead]
curtisszmania 2y ago
[dead]
ksec 2y ago
I am waiting for the author of HTMX's opinion on it. They dont seems to have commented here yet.
gred 2y ago
2025: > While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. 2033: > 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.

431 points by Kerrick 2y ago

deleted 2y ago

[deleted]

alterom 2y ago

Is that a proprietary HTML extension? Are we back to the IE-era mess then? If so, let's bring <marquee> back.

Frederation 2y ago
Man, that brought back memories.
finnthehuman 2y ago
>Is that a proprietary HTML extension? No, of course not. Web standards are whatever google decides they are.
shermantanktop 2y ago
Have you been following how HTML has evolved over the past 20 years? Your comment suggests not. It’s not entirely a standards-driven process. It’s common for browser vendors to just build stuff. That’s been a mixed blessing but it has definitely been faster than some W3C consortium debating “ergonomics” for years. Successful additions get backported into the spec, slowly.
- deleted 2y ago
  [deleted]
jdiff 2y ago
Doesn't appear to be. https://github.com/whatwg/html/pull/9841 https://github.com/whatwg/html/pull/9841 https://github.com/whatwg/html/issues/9625 https://github.com/whatwg/html/issues/9625 Seems to have been in the works since 2023, out in the open, with support from all major browser engines.
anamexis 2y ago
TFA links to the spec - https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-command https://html.spec.whatwg.org/multipage/form-elements.html#at... It's in Firefox and Safari
deleted 2y ago
[deleted]
hennell 2y ago
Marquee still works, we just don't tell marketing. https://caniuse.com/mdn-html_elements_marquee https://caniuse.com/mdn-html_elements_marquee
slt2021 2y ago
Chrome is the new IE. Whatever google decides will become a standard (both defacto due to them controlling the market and just shipping new version just in time and de-jure due to them financing W3C consortium and other standard bodies)

ykrishnan 2y ago

Is there an RFC for this?

teh_klev 2y ago
Start here I think: https://github.com/WebKit/standards-positions/issues/264 https://github.com/WebKit/standards-positions/issues/264

jt2190 2y ago

The specifications button element, commandfor armttribute: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-commandfor https://html.spec.whatwg.org/multipage/form-elements.html#at... button element, command attribute: https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-command https://html.spec.whatwg.org/multipage/form-elements.html#at...

msub2 2y ago

Invokers are not just a Chrome thing for those wondering, it's already in Firefox nightly as well https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonElement/commandForElement https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonE...

Kerrick 2y ago
WebKit has taken a "support" position. https://github.com/WebKit/standards-positions/issues/264 https://github.com/WebKit/standards-positions/issues/264
deleted 2y ago
[deleted]

QuadmasterXLII 2y ago

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

alterom 2y ago
>hopefully this leads to a surge in polite programming But not too polite. The compiler wouldn't like that.
- SAI_Peregrinus 2y ago
  Of course not. Sycophantic code is quite grating.
  - fuzztester 2y ago
    what's the download site for the psycho-fantic language? gimme! puhleeze.
- esafak 2y ago
  Demure is the fashion these days, I'm told.
  - mock-possum 2y ago
    Very.
  - BobbyTables2 2y ago
    Spoken like a bussin’ sigma that eats - no cap.

darth_avocado 2y ago

My dyslexic self got excited for command and conquer in HTML

netghost 2y ago
I definitely read about buttons waiting to see how this would unlock the ability to transpile Command and Conquer in some novel way. Still appreciate the new features though.
k6hkUZtLUM 2y ago
Me too. I was reading about buttons ... and wondering where was the game? Although, the buttons are very interesting.
DeathRay2K 2y ago
Just today I discovered there’s a Red Alert port to Three.js in the works: https://github.com/chongdashu/CnC_Red_Alert-ThreeJs https://github.com/chongdashu/CnC_Red_Alert-ThreeJs

TIPSIO 2y ago

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

error9348 2y ago

Would make interaction easier for ai agents on the web.

badc0ffee 2y ago
And screen readers.

vFunct 2y ago

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..

ericyd 2y ago
This is my thought too, I'm having trouble envisioning a case where a reasonably complex UI wouldn't still need JS. I guess it provides a roadmap to incremental adoption.
Someone1234 2y ago
The real power is custom commands and a standard way to implement them. The built-in commands will always be just conveniences that many convert to a custom version as complexity increases. Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
PokestarFan 2y ago
I don't see how it should be too hard to implement, you could abstractly have a system where the command string is translated as such: 1. Split the string by dashes into an array 2. Make the first character of the first array item lowercase, make the first character of the rest uppercase 3. Concatenate the pieces together 4. Do `document.getElementById(element.commandfor)[concatenated]()` Obviously this doesn't have the myriad number of checks to make sure that the element exists, the method exists, the method takes no parameters, etc. This would also allow custom commands easily, since you could do `document.getElementById(element.commandfor).myCustomMethod = function() { /* ... */ }`
- rafram 2y ago
  Given that this is meant to be a safe alternative to inline JS, executing arbitrary JS would be counterproductive.

gatinsama 2y ago

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

rsync 2y ago
No, it is terrible that "they" continue to extend and "improve" HTML. This is the reason it seems impossible for an independent web browser to be created and maintained: because what should be a simple and predictable spec over the last twenty years is a rapidly moving target that takes significant resources just to track. We could have ten different open-source web browsers (like Konqueror) if we weren't cramming the HTML spec full of bloat that nobody wants and that we all install extensions to disable anyway ...
- wruza 2y ago
  I’m pretty sure this is the only goal. Everyone with a neuron or two can see that the internet doesn’t use web tech and abstracts it away as soon as possible. These people just grow their corporate security by adding nonsensical bullshit that makes zero difference irl.
- wmanley 2y ago
  > We could have ten different open-source web browsers To what end?
  - hollowturtle 2y ago
    Sane competition, developers and end users would benefit from competition. This is just corporate lock-in. When a user is required to install Chrome for using a web app we're failing him as a platform, and the open web goes off the rail
  - johnfernow 2y ago
    Having a browser written entirely (or mostly) in a memory safe language. LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking. Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking. In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS. Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features. As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.

hoc 2y ago

Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here. 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'd expect to see lots of enhanvement requests once that box was opened :) There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.

dartos 2y ago
It’s not that the idea is brand new, just that it’s now implemented in chrome and in the web specs.
wruza 2y ago
You thought web was 15 years behind, but it quickly catches up to 30 years old tech! News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
- 9dev 2y ago
  What would have been something useful?

Starlord2048 2y ago

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

SamBam 2y ago
> Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist? The same way React or other frameworks can hook into things like CSS animations. If CSS animations didn't exist, the JS framework would have to write all the code themselves. With them existing, they can just set the properties and have it work. Even if you're writing a basic menu popup directly in React, having these properties to use directly in your JSX means less code and less room for error. Then if you need to do something special, you may need to do it by hand and not use these properties, just like if you needed a special animation you might have to do it without using the CSS animation properties.
- fitsumbelay 2y ago
  agreed, my sense is that frameworks will update to take advantage as they've done in the past
toomim 2y ago
> Is this just shifting complexity from JS to HTML? Very well said. This is the problem. There's an old adage that every "scripting" language starts out small, but then ultimately needs all the features of a full programming language. If we start putting programming features into HTML, we'll eventually turn it into a full turing-complete programming language, with loops, conditionals, variables, and function calls. We'll have recreated javascript, outside of javascript.

cratermoon 2y ago

I'd gladly give up this if I could get ublock origin and other pre v3 extensions back

ulrischa 2y ago

HTML seems to incubate some htmx things

lelandfe 2y ago

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

Izkata 2y ago
I think "light" is used as in "light touch" (soft touch), something that includes brushing against a surface by accident.
- efortis 2y ago
  I’d guess it stands for highlight. For example a modal is often highlighted by dimming and blurring the background.
david422 2y ago
Also random aside. I dislike this pattern for modal dialogs. Often times I will need to gather information from somewhere else, and in the process of attempting to get focus back to the dialog I've touched/tapped/clicked on something that dismisses the dialog. Very annoying.
- victorbjorklund 2y ago
  Most of the times that would be better solved with not using a modal.
- dylan-m 2y ago

prmph 2y ago

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

skydhash 2y ago
Flash? Silverlight? Swing?
- prmph 2y ago
  I see you are skeptical, but the failure of those technologies does not mean a new HTML-like platform cannot succeed. We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.
nullpoint420 2y ago
+1. The Web Platform is this interesting blend between declarative and imperative, but with the benefits of neither. IMO, the web platform needs a retained mode UI model like Qt Widgets, AppKit, or UIKit. Then desktop-like applications like Figma wouldn't need to compile to WASM and render WebGL for their UI. They could just treat <divs> as views or layers.
satvikpendem 2y ago
Ian Hickson, who authored the HTML5 spec and leads Flutter, has written about exactly this, Towards a Modern Web Stack [0][1], to create a new stack that can handle modern web applications. Flutter is a part of it but he talks about a more general (and generalizable) stack. He's on the HN thread as well expanding on the rationale behind it. Interestingly, it seems like specific people on HN don't exactly like it, a bit funny to witness their crash outs. [0] https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 [1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/preview?pli=1&resourcekey=0-bPajpoo9IBZpG__-uCBE6w&tab=t.0 https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... (actual doc to read)
- 2y ago

SoftTalker 2y ago

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

flowerthoughts 2y ago

Oh, this seems like a nice generalization of the popover specific attributes. Could replace <button type="submit"> with <button command="submit"> and default commandfor to the ancestor form.

_betty_ 2y ago
interesting, they could finally deprecate the form attribute on buttons...

fitsumbelay 2y ago

more builtin behavior, less JS to ship. pretty dope

fngjdflmdflg 2y ago

>the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes. At first I was worried because they just added the popover API recently, which itself replaced <dialog>, but this is still using the same API, just calling it from HTML differently. Still, I'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/pause functionality.[0] For a simple website, you don'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't necessary for simple websites. But then for websites that are more complex, you would already be using js presumably? I do mostly like what is written here about the project in general, which seems to answer the above question: >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. >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] 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'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? [0] linked in the article: https://open-ui.org/components/future-invokers.explainer/ https://open-ui.org/components/future-invokers.explainer/ [1] https://open-ui.org/charter/ https://open-ui.org/charter/

werdnapk 2y ago
The popover API is not a replacement for <dialog>. It's an alternative to some dialog like functionality if the use case is right.

slt2021 2y ago

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

naikrovek 2y ago
it looks clean, now. web devs will get ahold of this and demand that they have the ability to change the size, the animations of appearance and disappearance, specify a sound that plays when the menu is opened or closed, etc. I'm saying that this, like all other web things, will be bastardized and mutilated until it is just as complex and unworkable as the existing solutions which this is intended to replace.
- slt2021 2y ago
  I am fine if structural stuff can be coded in HTML, while animations and bells and whistles will still have to be JS/CSS based

Tarucho 2y ago

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.

karol 2y ago

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

kflgkans 2y ago
> That looks like more XSS vectors. Could you elaborate on that? I don't understand how this leads to more XSS vectors.
- karol 2y ago
  If these are proposals to use bindings between html attributes and calling JS methods, then it's enough to inject HTML, not JS, to start executing JS.
  - Keithamus 2y ago
    It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).

nikeee 2y ago

> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes. Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/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't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.

deleted 2y ago
[deleted]
mubou 2y ago
I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.

pavlov 2y ago

It’s just like the target / 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. It’s not exaggeration to say that the web has set UIs back by decades. 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.

naasking 2y ago
> It required several screenfuls of obscure and brittle code I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.
gear54rus 2y ago
> set UIs back Oh that's why 90% of online interactions are now on the web now ... stupid me thinking because it's a superior solution. And before you say '90% are actually on mobile', well mobile doesn't use shit from 1994 also. Wonder why.
- pavlov 2y ago
  Mobile absolutely uses “shit from 1994”. The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
  - mattl 2y ago
    Yep. All of the main 5 operating systems for consumers are from the late 80s and early 90s. - Windows 11 is Windows NT - macOS is NeXTSTEP/OPENSTEP - Linux is a free Unix like from the era where that was a new thing with both BSD and GNU working on it - Android is Linux + Java (inspired by OpenStep) - iOS/iPadOS is NeXTSTEP/OPENSTEP for phones. (OPENSTEP is an OS. OpenStep is a framework)
- deleted 2y ago
  [deleted]

roon_shady 2y ago

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

garganzol 2y ago

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

webnoob 2y ago

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

zerocrates 2y ago
Generally you do it the "document" way (often called a "delegated" listener) when you have lots of elements you want to listen to, or particularly elements that will be dynamically added and removed. If you listen directly to every target element, you have to find the elements and loop through them all, they have to exist at the time you set the listener, and you have to make sure to add the listener every time you add a new element that has the same behavior. If you listen at the document (or some appropriate parent element) and then check if the element that fired the event matches what you're trying to handle, you can have one listener that will apply to all the matching children regardless of where/when/how they're added.
irjoe 2y ago
Using document.addEventListener means it will work even if the DOM is updated without having to add new event listeners. If I'm not expecting the DOM to change I would be more inclined to do something like: document.querySelectorAll('.menu-wrapper')).forEach(menuWrapper => { const button = menuWrapper.querySelector('.menu-opener'); const content = menuWrapper.querySelector('.menu-content'); if (!content || !button) { return; } button.addEventListener(() => { button.setAttribute('aria-expanded', 'true'); menu.showPopover(); }); content.addEventListener('toggle', e => { // reset back to aria-expanded=false on close if (e.newState == 'closed') { button.setAttribute('aria-expanded', 'false'); } }); }); The React example seems a little odd as well, if the "open" callback actually called "showPopover()" instead of only calling "setIsOpen" then the "useEffect" could be entirely redundant. The resulting code would be a lot clearer imo.
- 2y ago

luismedel 2y ago

One more case of Fire and Motion[0] in the industry. [0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

jandrese 2y ago

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

jameshart 2y ago
The reason onclick is disallowed is because it permits full JavaScript execution. An onlick attribute is ‘eval’d on click. If you can inject one into a page you get JavaScript execution. Hence, content security blocking - a rule served up on the page saying ‘nothing in this page is supposed to have onclick attributes. If you see one ignore it’. These command attributes are not arbitrary JavaScript hooks. They tell inbuilt components to do inbuilt things. It doesn’t make sense for a content security policy to say ‘nothing on this page has commands, if you see something that does ignore it’, any more than it would make sense for a content security policy to say ‘nothing in this page is in bold, if you see something that says it wants to be displayed in bold ignore it’.
- crabmusket 2y ago
  This makes sense, but it feels like the case is overstated... Is it really common for sites to disable their own onclick attributes? Is it just the case that the CSP rule disables onclick in the HTML, but first party scripts can then attach event handlers separately?
  - jameshart 2y ago
    If you’re dynamically generating the HTML it’s safest to set the CSP to disable all inline scripts; you can permit only static scripts served from known good locations with valid sub resource integrity hashes.
- jandrese 2y ago
  Is it common that the HTML gets injected but inline scripts can not be injected at the same time?

mpalmer 2y ago

I don't know if it'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'm not particularly excited about using element IDs for yet another layer of web app behavior.

hdjrudni 2y ago
I don't like it either, but at least we can pave over it with a framework, unless you're allergic to those. It makes a good building block.
- mpalmer 2y ago
  True, and don't get me wrong, I think events are great and this will be a decent simplification, even with existing frameworks. If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.
conartist6 2y ago
I know what you mean
qwery 2y ago
Stringy code is my go-to example of a code smell. You can do it, it works and yes, as long as you write it correctly it will work correctly, but you're just kicking the can down the road, at best. HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired. It's a hack. This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
ximm 2y ago
I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.

CodeCompost 2y ago

This is basically HTMX. Why don't they just integrate it natively into the browser?

jl6 2y ago

Since it's all about buttons, it's a shame they missed the opportunity to call it butfor.

smitelli 2y ago
Sigh. Fine, I'll do it. What's a butfor?

adamredwoods 2y ago

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

stevenpetryk 2y ago
I’d much prefer el[‘show-popover’]()

cariaso 2y ago

everyone is crediting intercal but https://en.wikipedia.org/wiki/Comefrom https://en.wikipedia.org/wiki/Comefrom speaks to the history and rightly credits larry clark

layer8 2y ago

Next thing we’ll get DOM events beforecommand and aftercommand. /s 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.

jongjong 2y ago

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

chuckadams 2y ago
> What is the actual problem with onclick attribute? It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable? The alternative to on* attributes is addEventListener, which has also been a thing for decades.
- e12e 2y ago
  Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
- jongjong 2y ago
  Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused. With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data! I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.

Inviz 2y ago

Oh, it's coming back! Called for it: https://news.ycombinator.com/item?id=40888664 https://news.ycombinator.com/item?id=40888664

jongjong 2y ago

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'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.

DonHopkins 2y ago

HTML needs a <button type="revolt"/> to counteract the <button type="submit"/>.

jes5199 2y ago

wait, when did we get “dialog” and “popover” tags? these are wholly unfamiliar to me 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

tln 2y ago
<dialog> Chrome 37, Aug 2014 Safari 15.4, Mar 2022 popover attribute Chrome 114, May 2023 Safari 17, Sep 2023
- Zardoz84 2y ago
  Don't forget Firefox... There are some people that keeps trying to support anything that isn't f* controlled by Google or Apple. Dialog in Firefox 98 , 2022-03-08 Also, using a poly fill works even on IE 12 popover in Firefox 125, 2024-04-16

qwery 2y ago

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

afavour 2y ago
I like that but I’m not so sure. Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
- porridgeraisin 2y ago
  Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course) For example, sorting a table could be achieved by having the column headers be a link to the same url with ?sort_by={colname} And then the server sees that and sorts and returns. Same with "dynamic" number of input fields. When the add field link is clicked you reload with ?num_fields=2
  - afavour 2y ago
    To me that feels like a technicality. It’s the same experience you’d get with a button + JS except with more latency.
    - deleted 2y ago
      [deleted]
  - furyofantares 2y ago
    Yeah but that was also implemented as a button, right? input type="submit" would display a button in 1993 AFAIK. No javascript and acted like a hyperlink - but still a button.
    - 2y ago

vivzkestrel 2y ago

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

flakiness 2y ago

The author is not affiliated with Google. Is this from "external" 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.

Keithamus 2y ago
Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!

transfire 2y ago

Between this and other changes I worry they are just throwing more and more stuff at the wall to widen their browser moat. Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load. 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: #my-popover { display:= none; } #my-button:click { |> #my-popover { display:= block; } } Where `|>` retargets and the `=` indicates the property can undergo state changes. (Maybe the syntax could be better, but you get the idea.)

MacGyver101 2y ago

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

hollowturtle 2y ago

I'm wondering if these new html features will eventually get traction, anyone knows how's the usage of latest popover and dialog elements? I'm asking because I always wondered who would ever use them as JavaScript based dialogs are so ubiquitous and they can't easily be content blocked vs querySelectorAll("dialog") 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?

garganzol 2y ago
Google being Google, they may do it just for the sake of squeezing revenue from less likely blockable ad popups. This explains why they decided to work on HTML dialogs out of the blue. In their mind, dialog is popup, and an ad popup that you cannot block equals more money for them. Probably they are creating an area in specification for them to exploit in the future. In a twisted way of course, via extension manifest V4 or something like that.
- hollowturtle 2y ago
  I think you're confusing some stuff. A native dialog element as a popup is easier to block, for example, you just have to select all dialog elements by tag name and convert them to div inlined elements or something like that. Can't do the same reliably when the dialog is created by a javascript library using a div that uses a random id or generated class name
micromodel 2y ago
I don't know who else is doing it but my team and I always use semantic HTML, including dialog elements It is, unfortunately, the least I can do to respect the user, since I have no control over the decision to load horrible tracking scripts onto their browser.
- RobMurray 2y ago
  I really wish everyone would use semantic HTML wherever possible. The gains for accessibility are huge. Take a JS dialog or pop-up menu, for example. You would think it would be easy for everyone to use, but a screen reader user might not even be aware that it’s there in the first place. Even when they do, they still need to find it in a linear and possibly very cluttered representation of the page. It could be right next to the "open menu" button, at the bottom of the page, or somewhere else entirely. The menu/dialog could also disappear as soon as they move the focus in an attempt to find it! These are all things I put up with regularly. I think anything that makes accessibility easier for developers is a good thing, especially if it just works without having to think about accessibility.

TaurenHunter 2y ago

I've misread this excitedly as "Command and Conquer" for HTML thinking it had to do with the recently released source code.

tinodb 2y ago

Interestingly the examples don’t show interaction with <form>. 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? If I still need js to then submit the form it feels like this falls quite a bit short.

neuroelectron 2y ago

Someone was just telling me that Google doesn't have significant influence on web standards.

G_o_D 2y ago

77 2y ago
This hack has terrible accessibility. For one, the <label> is not focusable by default, so keyboard users won't be able to toggle the popup at all. And I don't think it's possible to dynamically set ARIA attributes without JS.

tarjei_huse 2y ago

This will be great! 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. Sidenote: I think the web's biggest problem in the future will be how hard it is to deprecate functionality. Maybe we need Html6 to be about removing/simplifying features from the browsers?

tonetheman 2y ago

[dead]

curtisszmania 2y ago

[dead]

ksec 2y ago

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

gred 2y ago

2025: > While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. 2033: > 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.