Web developers have long relied on JavaScript libraries and complex APIs to manage scroll-based animations, but a new proposal in the CSS Working Group aims to change that landscape. The emerging animation-trigger property, currently detailed in the experimental Animation Triggers specification, introduces native capabilities for delaying and controlling CSS animations based on specific named triggers.
While the feature is currently in its early stages as an Editor’s Draft and boasts limited browser support—appearing only in Chrome 145 and later—it signals a significant step forward for native styling capabilities. By allowing developers to listen for named triggers and control how an animation plays or pauses in response, the specification shifts behavior that has traditionally been the exclusive territory of JavaScript, such as the Intersection Observer API, directly into the stylesheet.
To understand how the feature operates in practice, consider a basic implementation where an element applies a fade-in animation governed by a trigger. By writing a rule such as .element animation: fade-in 0.35s ease-in-out both; animation-trigger: --trigger play-forwards play-backwards; , the browser waits for the specified trigger event before executing the declared style changes.
Crucially, the introduction of scroll-triggered animations requires a clear distinction from scroll-driven animations, a concept that has recently gained traction in modern web design. Although both paradigms rely heavily on scroll or view timelines, they represent fundamentally different approaches to handling motion on the web.
In a scroll-driven animation, an element’s progress is directly and continuously tied to the user’s scroll position. As the user scrolls up or down the page, the animation scrubs forward or backward in absolute synchronization with the timeline. There is no concept of a discrete starting moment or a firing event; the animation is a direct visual translation of the scroll metric.
In contrast, scroll-triggered animations are state-based rather than continuous. A trigger possesses a binary state, and when a predefined condition is met—such as an element entering a specific viewport range—the trigger fires an associated action, such as playing, pausing, or resetting an animation. Once the trigger has fired, the animation behaves essentially like a regular CSS animation, running its course independently of ongoing scroll progress unless a subsequent exit action alters its state.
The "trigger" referenced in the animation-trigger property can refer to either timeline-based triggers, such as scroll or view progress timelines, or event-based triggers tied to DOM interactions like a user click. The core framework centers on defining a custom timeline trigger first, establishing the conditions under which an animation should begin based on an element’s position within a timeline or viewport.
Setting up a timeline trigger involves declaring a custom name to link it to the animation-trigger property, followed by a source timeline function such as view() or scroll(). Developers then specify an activation range to dictate the exact moment the trigger activates within the viewport, alongside an optional active range that defines the broader outer boundary where the trigger remains active before turning off.
By default, trigger names possess a global scope throughout the stylesheet. If multiple elements happen to define the exact same trigger name, the browser selects the element that appears later in the cascade. However, developers can also restrict the scope of a trigger to a specific DOM subtree by utilizing the accompanying trigger-scope property.
The flexibility of the system stems from its diverse array of animation actions, which dictate how an element responds when entering or exiting a trigger’s active range. Developers can mix and match these actions to achieve varied behaviors from a single underlying trigger, allowing elements to fade, slide, or transform dynamically as users navigate through a document. Furthermore, triggers and animations do not necessarily need to reside on the same DOM element. A timeline trigger can be defined on a parent container, while the animation-trigger property is applied to multiple child elements, ensuring that an entire group of elements can animate simultaneously the moment the parent enters the viewport.
As defined in the official W3C Editor’s Drafts, the specification remains fluid, meaning that syntax, property names, and behavior details are subject to change before the proposal advances toward Candidate Recommendation status. Web developers interested in experimenting with the feature will need to monitor browser compatibility closely, as implementation is currently restricted to experimental environments in modern desktop browsers like Chrome.
