CSS
CSS Animation Triggers Splits Off Into Its Own W3C Spec
The CSS Working Group carved animation-trigger out of css-animations-2 into a dedicated Draft Standard on 20 October 2026 — a signal it's heading toward real cross-browser support.
The CSS Working Group carved animation-trigger out of css-animations-2 into a dedicated Draft Standard on 20 October 2026 — a signal it's heading toward real cross-browser support.
On 20 October 2026, the W3C CSS Working Group published Animation Triggers as its own Draft Standard, pulling the animation-trigger property and its supporting timeline-trigger machinery out of the old css-animations-2 module and the retired web-animations-2 draft. It's a housekeeping move on paper, but it's the kind of housekeeping that precedes real adoption: specs get split into focused modules once a feature is stable enough to test, implement, and ship independently — and teams doing SaaS platform development should care, because this is the piece that finally lets a scroll event start a CSS animation without a line of JavaScript.
Nothing in the behavior of animation-trigger changed on 20 October — this was a spec-organization update, not a new feature drop. Before the split, the triggered-animations text lived awkwardly across two documents: part of it was bolted onto CSS Animations Level 2, and part of it had been drafted under the abandoned Web Animations Level 2 umbrella. Animation Triggers Level 1 is now the single source of truth for three properties working together:
animation-trigger — names which trigger an animation listens to and what it does when the trigger fires or resets (play-forwards, play-backwards, and combinations of the two)timeline-trigger-name — gives a trigger a custom identifier, the same way timeline-scope names a scroll timelinetimeline-trigger-source — defines what fires the trigger: a view() progress timeline (an element entering or leaving the viewport) is the main case todaySplitting it out matters for the same reason scroll-driven animations got their own module before they shipped widely: a focused spec is easier for browser teams to implement against, easier for Web Platform Tests to cover in isolation, and easier for the community to nominate for an Interop year. Scroll-triggered animation is already on the radar for Interop 2027 proposal ranking, and a dedicated spec is the usual precondition for that conversation to go anywhere.
It's easy to conflate the two, so here's the distinction that actually matters for your CSS. A scroll-driven animation (animation-timeline: scroll() or view()) ties an animation's progress directly to scroll position — scrub a progress bar up as the user scrolls down, frame by frame, with no concept of duration. An animation trigger is different: it uses a timeline only to decide when to start a normal, time-based animation. Once triggered, the animation plays out with its own duration and easing, independent of further scrolling.
#card {
animation: fade-in-up 0.6s ease-out both;
animation-trigger: --reveal play-forwards play-backwards;
}
#card-sentinel {
timeline-trigger-name: --reveal;
timeline-trigger-source: view();
}That's the entire reveal-on-scroll pattern — no IntersectionObserver, no scroll listener, no JavaScript bundle. It's the same job libraries like AOS and ScrollReveal exist to do, expressed as three CSS declarations.
Practically, three things follow from the spec split:
animation-trigger ships in Chrome and Edge 146+, but Firefox and Safari don't support it. Wrap any production use in a @supports check and keep your JavaScript fallback until support is closer to Baseline.css-animations-2 for trigger behavior is now stale; the canonical definition lives at animation-triggers-1.@supports not (timeline-trigger-source: view()) {
.card { /* JS-driven fallback class applies here */ }
}There's no shipping date attached to the spec split itself — Draft Standard status means the text is stable enough to implement against, not that it's locked for Candidate Recommendation. The realistic path: continued Chromium-only support through the rest of 2026, a push for broader adoption if scroll-triggered animation is selected for Interop 2027 (final scope expected around February 2027), and Baseline-worthy cross-browser support arriving only after Firefox and Safari ship their own implementations — which has no committed date yet. Track the Interop proposal tracker if you want the earliest signal on when that changes.
For progressive enhancement, yes — pair it with a @supports fallback and let Chromium users get the free native effect while everyone else gets your existing JavaScript. For anything that has to look identical everywhere on day one — a client deliverable, a SaaS onboarding flow, a marketing page under deadline — keep the JS library as primary and treat animation-trigger as a performance upgrade you can drop in later, once it clears Firefox and Safari, with zero markup changes required.