CSS Just Ate JavaScript's Lunch (And Nobody

Here's something I never thought I'd write: CSS now has if statements and functions. Actual programming constructs. The kind of thing that would have gotten you laughed out of a conference room in 2010 when CSS was still figuring out how to center a div reliably.

Chrome's annual CSS Wrapped roundup for 2025 landed this week, and buried in the usual parade of incremental improvements is something more interesting—CSS is quietly absorbing capabilities that used to require JavaScript. Not just "technically possible but painful" absorption. Actually good, actually usable features that solve real problems.

The Joy of Code channel walked through twenty of these features, and I'm not here to recap all of them. You can read the Chrome blog post if you want the full catalog. What's worth examining is the pattern: CSS is becoming less about styling and more about behavior.

The JavaScript Diet

Take carousels. If you've built websites professionally, you know carousels are a special kind of hell. You need JavaScript to handle the navigation, track state, manage accessibility, deal with touch events versus mouse clicks, handle keyboard navigation, and oh god we haven't even talked about making it work on mobile yet.

Now? CSS has ::scroll-button and ::scroll-marker pseudo-elements. As the video demonstrates: "Now we can use CSS to create buttons and control the carousel instead of using JavaScript. And I don't actually know or can think of any other CSS feature like that."

The buttons are browser-provided, stateful, interactive, focusable, and automatically disable when scrolling isn't possible in a direction. All the accessibility work you'd normally have to implement by hand? The browser handles it. You just style the thing.

This isn't a polyfill. This isn't a framework workaround. This is native CSS saying "we'll take it from here."

The Invoker Pattern

Or look at invoker commands. Previously, showing a modal dialog required JavaScript—query the element, call showModal(), set up event handlers for closing it. Standard stuff, twenty lines of code you've written a thousand times.

Now you can use the command attribute in HTML: command="showModal" and commandfor="my-dialog". That's it. No JavaScript. The browser knows what to do.

The video creator notes you can even create custom commands if you need them, listening for command events in JavaScript when you need something beyond the standard set. But for the common cases—showing dialogs, toggling popovers—you're done.

What's interesting here isn't just the feature. It's the design philosophy. CSS is moving toward declarative UI patterns that used to require imperative JavaScript code. You're describing what should happen, not how to make it happen.

The Spy Who Scrolled Me

Scroll-spy navigation is another example. You know those table-of-contents sidebars that highlight which section you're currently reading? That used to require Intersection Observers, state management, and a bunch of JavaScript to track which heading was visible.

The new scroll-target-group property with the :target-current pseudo-class handles it in CSS. As the video demonstrates: "This is so much easier than using JavaScript and observing these elements and doing whatever, right? And it just works."

Two properties. That's the entire implementation. The JavaScript version required understanding observer APIs, managing thresholds, handling edge cases when sections are smaller than the viewport. Now it's CSS.

Sibling Rivalry

The sibling-index() and sibling-count() functions solve a problem I've hit repeatedly: staggering animations. You want each item in a list to animate in sequence, slightly delayed from the previous one.

Traditionally, you'd use JavaScript to add index attributes to each element by hand or programmatically, then reference those in your CSS. Or you'd use a preprocessor with loops. Both approaches were clunky.

Now: transition-delay: calc(0.1s * (sibling-index() - 1)). CSS natively knows where each element sits among its siblings. No JavaScript. No build step. It just works.

These aren't headline features. They're the kind of small improvements that compound over time—death by a thousand paper cuts in reverse.

The Browser Compatibility Question

You're probably thinking: "Cool features Mike, but what's the browser support?" Fair question. The video addresses this upfront: "Even though some of those features aren't supported in all of the browsers, most of them have a polyfill that you can use."

Which is where this gets interesting. Polyfills for CSS features used to be terrible—JavaScript hacks that never quite worked right. But modern CSS polyfills are often surprisingly good because the feature is already well-specified. The browser just hasn't implemented it yet.

Still, the practical reality is these features are most useful if you control your environment (internal tools, enterprise apps) or can afford to serve enhanced experiences to modern browsers while falling back gracefully.

The customizable <select> element is probably the most immediately useful across the board. Developers have been fighting with select styling since roughly 1997. Now you can use appearance: base-select and access pseudo-elements like ::picker-icon and ::picker-option. You can put actual HTML inside select options—images, spans, whatever you need.

As the video notes: "You can make any type of select menu that you want. You can make a radial select menu and so on." Which means we might finally stop building custom dropdown components from scratch.

What This Actually Means

I've watched enough technology cycles to know that "X will replace Y" predictions are usually wrong. CSS isn't replacing JavaScript. You still need JavaScript for actual application logic, data handling, complex interactions.

But the boundary is shifting. Things that used to require JavaScript because CSS couldn't handle them are increasingly things CSS can handle just fine. The carousel example is telling—not because carousels are important, but because they represent a class of problems (interactive UI components with state) that used to live firmly in JavaScript territory.

The if statements and custom functions mentioned in the intro? Those are even more interesting. CSS is acquiring computational capabilities that blur the line between styling language and programming language. We're not there yet—these are early-stage features—but the direction is clear.

What we're seeing is CSS becoming more capable at the exact moment that JavaScript frameworks are becoming more complex. React Server Components, signals, fine-grained reactivity—the JavaScript ecosystem keeps adding layers of abstraction. Meanwhile CSS is saying "maybe you don't need all that for a tooltip."

The question isn't whether CSS will replace JavaScript. It's whether the industry will notice that the boundary moved and adjust accordingly. Based on the number of developers still reaching for JavaScript libraries to solve problems CSS now handles natively, I'm not optimistic about rapid adoption.

But the features are there. And they work. And eventually, that tends to matter.

—Mike Sullivan, Technology Correspondent