The Browser Learned New Tricks. Your JS Backlog Just Got Shorter.

For years, the fun interaction stuff meant JavaScript. Scroll effects, cursor tracking, contrast checks, animated dialogs. Someone on your team wrote it, someone maintained it, and it broke in weird ways. That deal is changing. The browser now does a lot of it on its own.

Let me catch you up on what shipped, what it saves you, and where the sharp edges still are.

Scroll effects without the observer code

Chrome shipped scroll-triggered animations, and it's the first browser to do it. The CSS-Tricks first look frames it plainly: think JavaScript's Intersection Observer, but in CSS. An animation fires for a set duration once an element crosses a scroll threshold. No listener, no library.

That's separate from scroll-driven animations, which tie an animation's progress to how far you've scrolled. One CSS-Tricks demo builds columns that slide in opposite directions using only animation-timeline: view() and a couple of keyframes. The kind of thing that used to be a scroll plugin is now a handful of CSS lines.

The upside for your team: fewer moving parts, less code to babysit, and effects that respect reduced-motion settings by default. The catch is browser support, which I'll get to.

The data JS used to hand off

Cursor position. Scroll velocity. Current time. Form states. That's the stuff JavaScript would sniff and pass to CSS through custom properties. Adam Argyle's Prop For That turns those into live CSS variables. You import the library, add a data attribute like data-props-for="pointer", and read --live-pointer-x straight in your styles.

The script still runs in the background. It's just wrapped so your team writes CSS instead of wiring up event handlers by hand. For a design team that wants interactive polish without a big JS commitment, that's a real shortcut.

Accessibility the platform handles for you

A lot of the new native features do accessibility work you used to hand-code. The contrast-color() function, now Baseline as of Chrome 147, takes a background color and returns black or white based on which reads better. No more maintaining two color systems for high contrast.

The April Baseline digest makes the broader point: bespoke JS built to fake accessible patterns is fragile and breaks under assistive tech. The <search> element now gives you a search landmark for free. ARIA attributes reflect as plain properties, so element.ariaExpanded replaces a setAttribute roundtrip. The platform exposes the right semantics without a custom fix.

So when a review asks "is this accessible," the honest answer is getting closer to "yes, because the browser does it," not "yes, because someone wrote 200 lines to fake it."

Read the Baseline date, not the browser name

Here's where teams trip. Native does not mean everywhere yet. Scroll-triggered animations are Chrome-only right now. The opposing-columns demo notes Firefox support is still missing and wraps the effect in @supports. web.dev even pulled a claim that scroll-driven range properties had hit Baseline, because they hadn't shipped in Firefox.

Rachel Andrew's take, flagged in the March digest, is worth stealing: treat your Baseline target as a point in time, not a browser list. Pick a later target and you get more features but narrower reach. Line the target up with your launch date so you're not skipping things you could safely use on day one.

The deep cut

These wins land unevenly, and that's the part to plan around. contrast-color(), :open, name-only container queries, and CSS functions are Baseline or close, so they're safe to build on now. Scroll-triggered and scroll-driven animations are still Chrome and Safari territory with Firefox lagging, so they need @supports fallbacks or they stay in the "nice enhancement" bucket.

What this actually changes: your JS backlog has line items you can delete. Custom cursor tracking, hand-rolled contrast logic, Intersection Observer scroll reveals, faked ARIA states. Have your team pull the What's !important roundup and the monthly Baseline digests, map each new feature to code you already own, and mark what's safe to swap versus what needs a fallback. That's a real cleanup sprint, not a research project.

Three questions for your team

1. Which effects in our current build lean on JS that a native CSS feature now covers, and which of those are Baseline enough to swap this quarter?
2. What Baseline target are we building against, and does it match our next launch date or a stale default?
3. For the Chrome-only wins like scroll-triggered animations, do we have a clean @supports fallback, or are we shipping a broken experience to Firefox users?