Chrome 146 Brings Scroll-Triggered Animations to the Browser
Web animation has always been a space full of creative tension — developers want rich, responsive motion, but browsers have historically forced them to lean on JavaScript to get there. That changed in a meaningful way with the release of Chrome 146, which ships scroll-triggered animations as a native CSS feature. Chrome is the first browser to support this capability, marking a significant milestone for frontend development and the broader web platform.
If you have Chrome 146 installed, you can already see it in action. A simple demo illustrates the concept well: the background of a square element fades in over a duration of 300ms, but only once the entire element is fully within the viewport. No JavaScript. No event listeners. No third-party libraries. Just CSS doing what we have long wished it could do on its own.
This article breaks down what scroll-triggered animations are, how they differ from scroll-driven animations (a related but distinct feature), and how you can start using them in your own projects right now.
What Are Scroll-Triggered Animations?
At their core, scroll-triggered animations are CSS animations that begin playing once a defined scroll threshold has been crossed. The animation itself runs for a fixed duration — it is not tied to how far the user has scrolled. Instead, reaching a certain scroll position (or viewport condition) acts as the trigger, and the animation simply plays out from start to finish as it normally would.
The closest conceptual equivalent in JavaScript is the Intersection Observer API. Developers have used Intersection Observer for years to detect when elements enter or leave the viewport and then programmatically add classes or trigger animations in response. Scroll-triggered animations in CSS are essentially that same idea, but baked natively into the browser's animation engine and expressed entirely through stylesheet declarations.
This is a meaningful shift. By moving this logic into CSS, browsers can optimize execution, reduce main-thread overhead, and allow developers to keep animation concerns where they arguably belong — in the presentation layer.
Scroll-Triggered Animations vs. Scroll-Driven Animations
It is easy to conflate scroll-triggered animations with scroll-driven animations, especially since both entered the CSS conversation around the same time and both relate to scroll behavior. However, they are fundamentally different in how they operate.
Scroll-Driven Animations
Scroll-driven animations tie animation progress directly to scroll progress. As the user scrolls down, the animation advances. As the user scrolls back up, the animation reverses. The animation state at any given moment is a direct function of the scroll position. This is great for effects like parallax backgrounds, reading progress indicators, or revealing elements as they move through the viewport in a fluid, continuous way.
Scroll-driven animations use animation-timeline with values like scroll() or view() to establish this synchronization between the scroll container and the animation timeline.
Scroll-Triggered Animations
Scroll-triggered animations, by contrast, are not synchronized with scroll position at all. They simply watch for a scroll condition to be met — typically an element reaching a certain visibility threshold within the viewport — and once that condition is satisfied, the animation fires and plays for its full specified duration. Scrolling backward does not reverse it. The animation plays once (or loops, if configured to do so) and that is that.
Think of it this way: scroll-driven animations are like a movie whose playback speed is controlled by your scroll wheel, while scroll-triggered animations are like pressing play on a video — the scroll just determines when play gets pressed.
This distinction matters enormously when choosing the right tool for a given effect. Want an element to gradually reveal itself as it enters the viewport in direct proportion to scroll? Use scroll-driven. Want an element to animate in cleanly with a polished transition the moment it fully enters the viewport? Use scroll-triggered.
Why This Feature Matters for Modern Web Development
The practical implications of native scroll-triggered animations extend well beyond convenience. There are several reasons why this addition to the CSS specification is genuinely exciting for developers and users alike.
- Performance gains: JavaScript-based scroll watchers and Intersection Observer callbacks run on the main thread and can contribute to jank if not carefully managed. Native CSS animations, especially those composited by the browser, can run off the main thread entirely, resulting in smoother animations even on lower-powered devices.
- Reduced JavaScript dependency: Less JavaScript means smaller bundles, fewer potential points of failure, and a cleaner separation of concerns between behavior and presentation.
- Accessibility alignment: CSS animations automatically respect the
prefers-reduced-motionmedia query when properly implemented, making it easier to build accessible animated experiences without duplicating logic across stylesheet and script files. - Simpler code maintenance: When animation logic lives in CSS rather than scattered across JavaScript event handlers, it is far easier for teams to read, update, and maintain over time.
Browser Support and What to Expect Next
As of the writing of this article, Chrome 146 is the first and only browser to ship scroll-triggered animations. Firefox and Safari have not yet implemented the feature, which means it is not yet safe to rely on it for production experiences that need universal cross-browser support — at least not without a fallback strategy in place.
That said, being the first browser to ship a feature like this is typically a strong signal that the broader ecosystem will follow. The specification work underpinning scroll-triggered animations is part of the larger Web Animations and CSS Animations Level 2 ecosystem, which has been gaining momentum across all major browser vendors. Watching the Can I Use page for this feature over the coming months will be worthwhile.
In the meantime, you can use scroll-triggered animations as a progressive enhancement — providing the animated experience for Chrome users while ensuring that non-supporting browsers simply display the element in its final, visible state without any animation.
Getting Started with Scroll-Triggered Animations
The syntax for scroll-triggered animations builds on the existing CSS animation model, which means if you are already comfortable writing keyframe animations, the learning curve is relatively gentle. The key addition is a mechanism to declare when the animation should be triggered based on the element's position relative to the viewport or a scroll container.
A basic implementation looks something like this: you define a @keyframes rule for the visual transition you want, apply it to an element using animation shorthand properties, and then attach the scroll trigger condition. Once the element crosses the defined visibility threshold — for example, when the entire element is within the viewport — the animation fires and completes its 300ms duration as defined.
You can control granular details like the threshold at which the animation fires, whether it plays once or repeats, and how the element appears before the animation begins. The result is a level of declarative control over scroll-based animation that previously required either a JavaScript utility library or careful manual orchestration with the Intersection Observer API.
The Bigger Picture for CSS Animation
Scroll-triggered animations are not just a useful new feature in isolation — they represent a continuing trend of the CSS specification absorbing animation and interaction patterns that previously belonged exclusively to JavaScript. Between scroll-driven animations, the View Transitions API, the @starting-style rule for entry animations, and now scroll-triggered animations, the CSS platform in 2025 and 2026 is dramatically more expressive than it was even a few years ago.
For developers building content-heavy websites, marketing pages, portfolios, and editorial experiences, the ability to orchestrate rich scroll-based animations entirely in CSS — without a single line of JavaScript — is a genuine quality-of-life improvement. It leads to faster pages, more maintainable codebases, and animations that degrade gracefully when the browser or user preference calls for it.
Chrome 146 may be just the beginning. Keep an eye on this feature as the specification matures and other browsers begin their own implementation work. The future of scroll animation in CSS looks very promising indeed.