CSS Learned Your Interactions So JavaScript Doesn't Have To

Your team keeps writing JavaScript to do jobs CSS can now handle on its own. Hover states, focus rules, form validity, open and closed panels, even animations tied to a click. That line between "CSS handles the look" and "JS handles the behavior" has been moving for a while. It moved again in the last few weeks. Let me catch you up.

Less code for the same interaction

CSS keeps adding pseudo-classes that act like event listeners. They track states, not events, but for your team the effect is the same: fewer lines of JavaScript to wire up. The CSS-Tricks rundown of these pseudo-classes walks through the ones you already lean on JS for. :focus-within styles a form when anything inside it has focus. :has() does the same with any selector. :open and :popover-open tell you when a dialog or popover is showing. No addEventListener, no state variable, no cleanup.

Some of these are hard to do well in JavaScript at all. :focus-visible uses browser heuristics to decide when to show a focus ring, based on whether someone is using a keyboard. There is no :autofill event you can listen for cleanly. The pseudo-class just works.

The small wins that add up

A couple of layout features shipped that used to need workarounds. field-sizing: content sizes a <select> to its chosen option, and it became Baseline when Firefox 152 shipped it. Watch one thing: it overrides the size attribute, so a <select size="3"> shows all options instead of three. Worth a note in your review before someone files it as a bug.

Gap decorations are the other one. Those are the spaces between items in flexbox, grid, or multi-column layouts. You can now style them directly, which kills a pile of border and pseudo-element hacks. Modern theming with @property, light-dark(), and contrast-color() is Baseline too. These are not headline features. They are the small chores your engineers keep coding by hand.

The animation trigger that is not here yet

The bigger shift is coming, not shipped. There is a proposal called event-trigger that lets a click or hover fire a CSS animation with no JavaScript. You name the trigger, point an animation at it, and CSS runs the rest. One element's event can even drive another element's animation.

Right now no browser supports it. So treat it as a roadmap signal, not a Monday task. The direction is clear: CSS is picking up jobs that used to be pure behavior. The author of that piece frames it right when he calls it an appreciation for what CSS simplifies, not a "JavaScript bad" rant. You still reach for JS when you need real logic, DOM traversal, or a method call. The question is where the line sits now, not whether JS still matters.

The deep cut

Every pseudo-class you move off JavaScript is code your team no longer has to test, mock, or keep in sync. That is the real payoff, and the testing pieces in this cluster show why. The Nuxt testing guide spells out how much scaffolding a JS interaction drags along: you mock the router, stub components, register fake endpoints, and pick the right environment before you can even check that a link points where it should. A CSS state has none of that overhead. So when you audit your components, don't just ask "can CSS do this now?" Ask "how many tests and how much mocking does this JavaScript version cost us to keep alive?" That number is where the savings actually live.

Three questions for your team

• Which interactions in our component library are still hand-wired in JavaScript that a pseudo-class like :has(), :focus-within, or :open now covers?
• Where are we shipping border and pseudo-element hacks for spacing that gap decorations would replace, and is field-sizing on our list before we build another custom select?
• How much of our test and mock setup exists only to cover JS-driven states, and how much of that goes away if we move those states to CSS?