For years, frontend development has had a slightly embarrassing relationship with HTML. We all read about semantic HTML, we talk about using the ri...
For further actions, you may consider blocking this person and/or reporting abuse
This is a really good reminder that the browser platform is evolving faster than a lot of our usual frontend patterns.
The part about LLMs reproducing older JS/React boilerplate is especially interesting. We often reach for state and event handlers before checking whether the platform already has a native solution.
command + commandfor looks like a small API change, but the bigger win is reducing unnecessary UI state and letting the browser own the interaction. Progressive enhancement with a feature-detected fallback also feels like the right approach while support continues to mature.
Definitely adding this to my list of APIs to experiment with. 🚀
Good CSS/HTML coverage. The landscape here moves quickly — worth noting that container queries and :has() selector support have reached baseline, which can simplify many of the responsive patterns we previously needed JS for.
Yes this are cool additions, i want to probably write about them too! Too many things to get excited, too little time.
The struggle of having an overflowing backlog of exciting web platform features is incredibly real. If you do tackle the Invoker Commands API, narrowing the scope to something like custom dialog controls might save you some research time while still delivering high value to your readers. Feel free to reach out if you want to trade notes on the spec before you start drafting.
thanks you for the knowledge realy interesting
really appreciate a good human-written post! Just useful and straight to the point information!
Tell me about it! Back in the day, we had to attach an event listener to literally everything just to open a simple modal 😂
Modern HTML is making web dev so much smoother and less overwhelming for beginners. Loved this update
Nice reminder that browser-native features can replace a lot of UI state. I’d pair this with feature detection and a graceful fallback, since support may vary across browsers.
Absolutely! I think the biggest benefit is reducing unnecessary JavaScript for interactions the browser can already handle. It’s easy to fall back on familiar React patterns, so it’s refreshing to see native APIs getting more capable. Definitely something worth experimenting with. 🚀
I see…! Even with coding, learning materials can be outdated, so you can end up learning outdated approaches too. This gave me a new perspective. Thank you!
thank you for great post
tbh html was always cool
i think you are right! people take it for granted!
Great article, Alexandra! You hit the nail on the head regarding LLMs suggesting outdated boilerplate. For those of us who still need to support older devices, I've been using a 'Progressive Enhancement' approach: I use the new
commandandcommandforattributes in HTML, and wrap the traditional JSaddEventListenerfallback inside anif (!('commandFor' in HTMLButtonElement.prototype))check. This way, modern browsers get the zero-JS benefit, and older ones still work perfectly. Thanks for highlighting this shift!😊Keep up the great work, and wishing you continued success and growth!
🗻🧊🌊
Yes, for simple websites this is the way to backward competability. For more advanced, there are always the invokers polyfills!
Great article, Alexandra! It's so refreshing to see the web platform naturally evolve to handle interactive behaviors we've been over-engineering with custom JS for years.
A few thoughts that really stood out to me:
The AI training point is spot-on. Highlighting how LLMs tend to regurgitate legacy boilerplate because they're trained on historical code is such a sharp observation. It’s a great reminder that browser standards are moving faster than AI code generators.
Shift in responsibility > saving lines of code. The biggest win here isn't just deleting 10 lines of JavaScript; it's moving state out of our components and back into the DOM where it belongs. Fewer sync bugs and built-in accessibility out of the box is huge.
Quick question: what’s your go-to strategy or polyfill for progressive enhancement here? Since cross-browser support only hit Baseline late last year, I'd love to know how you'd recommend handling fallback behavior for older client environments without duplicating logic!
For Invoker Commands, there are already polyfills that feature-detect native support and provide the missing behavior only when needed. For example, invokers-polyfill supports the standard command/commandfor API and falls back to JavaScript for browsers that don't support it.
For a simple interaction, though, you don't necessarily need a full polyfill. You can feature-detect support and provide a tiny fallback yourself; just check if the commandFor is in prototype, then you can show/hide dialogs/popovers.
The durable part of this approach is the feedback loop. If the team can reproduce the condition, measure the impact, and keep a regression test close to the change, the learning survives beyond the original incident.
huh?
Good CSS/HTML coverage. We just launched a free image toolbox at tools.shopveigo.com — the client-side image processing uses a lot of modern CSS and Canvas APIs. Frontend devs might find it interesting.
Show-modal on the Delete account button gets the dialog up with commandfor and no click handler, and command=close on cancel shuts it. The confirm still has to do the delete though. No matter how much of the open and close you hand off, there is still gonna be a delete call that fails and leaves the account sitting right there
Sure, but this is an interactivity to an action, which is a fair use of javascript. We are talking about handing over the responsibility to the browser on rendering the dialogs.