CSS Scroll Animation — Interactive Examples & Code

How to Add Scroll Animations to Fullscreen Sections

Element animations with afterLoad

Use the fullPage.js afterLoad callback to trigger CSS animations on individual elements when a section comes into view:

new fullpage('#fullpage', {
  afterLoad: function(origin, destination) {
    // Animate elements in the new section
    destination.item.querySelectorAll('[data-anim]')
      .forEach(function(el) {
        el.classList.add('visible');
      });
  },
  onLeave: function(origin) {
    // Reset animations in the section being left
    origin.item.querySelectorAll('[data-anim]')
      .forEach(function(el) {
        el.classList.remove('visible');
      });
  }
});

Section transitions with Effects extension

For the transition between sections (how one section morphs into the next), add the Effects extension for CSS transform presets:

new fullpage('#fullpage', {
  effects: 'cube',   // 20+ presets: stack, cover, vortex, zoom...
  afterLoad: function(origin, destination) {
    // Element animations still work alongside section transitions
    destination.item.querySelectorAll('[data-anim]')
      .forEach(function(el) { el.classList.add('visible'); });
  }
});

CSS Scroll-Driven Animations Explained

The CSS Scroll-Driven Animations specification replaces the old pattern of reading window.scrollY in JavaScript and applying styles imperatively. Instead, you declare that a standard @keyframes animation should be driven by scroll position rather than elapsed time.

Where animation-duration: 1s normally runs an animation over one second of wall-clock time, animation-timeline: scroll() or animation-timeline: view() replaces that clock with a scroll timeline. The animation's progress (0% → 100%) maps directly to a scroll offset.

The spec defines two timeline types: Scroll Progress Timelines, linked to the scroll position of a container, and View Progress Timelines, linked to an element's visibility within the viewport. Most practical use cases come down to choosing between these two.

scroll() vs view(): What's the Difference?

These two timeline functions track fundamentally different things, and picking the wrong one is a common mistake.

scroll() — Scroll Progress Timeline

animation-timeline: scroll() maps animation progress to the scroll container's overall scroll position: 0% at the top, 100% at the bottom. The animated element's position in the viewport is irrelevant; only the container's scroll offset matters.

Use it for effects tied to page-level scroll: reading progress bars, sticky header transitions, background parallax.

/* Progress bar that fills as user scrolls the page */
#progress-bar {
  animation: grow-width linear both;
  animation-timeline: scroll(root block);
}

@keyframes grow-width {
  from { width: 0%; }
  to   { width: 100%; }
}

view() — View Progress Timeline

animation-timeline: view() maps animation progress to an element's position within the scrollport. Progress advances as the element moves through the visible area, from its bottom edge entering (entry) to its top edge exiting (exit).

Each element gets its own independent timeline. Combined with animation-range, you can restrict the animation to a specific phase, e.g. entry 0% entry 100% for entrance only, or cover 0% cover 100% while fully visible.

/* Card that fades in as it enters the viewport */
.card {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

@keyframes fade-up {
  from { opacity: 0; transform: translateY(40px); }
  to   { opacity: 1; transform: translateY(0); }
}

Key Differences at a Glance

Core CSS Properties for Scroll Animation

Four CSS properties form the core of the spec.

animation-timeline

Replaces the time-based animation clock with a scroll or view timeline. Accepts scroll(), view(), or a named timeline reference. When set, animation-duration is ignored; scroll position controls progress instead.

/* Named timeline defined on a container, consumed by a child */
.container { scroll-timeline-name: --my-scroll; }
.child      { animation-timeline: --my-scroll; }

scroll-timeline

Defines a named Scroll Progress Timeline on a scroll container, so descendant elements can consume it via animation-timeline: --name. Shorthand for scroll-timeline-name and scroll-timeline-axis (default: block).

.scroll-container {
  overflow-y: scroll;
  scroll-timeline: --page-scroll block;
}

view-timeline

Defines a named View Progress Timeline on an element, referenceable by siblings or descendants. Shorthand for view-timeline-name, view-timeline-axis, and view-timeline-inset. The inset value adjusts the effective scrollport boundary, letting you trigger animations before or after the element fully enters.

.hero-image {
  view-timeline: --hero-reveal block;
}
.hero-caption {
  animation: reveal linear both;
  animation-timeline: --hero-reveal;
  animation-range: entry 50% entry 100%;
}

animation-range

Restricts which portion of the timeline drives the animation. Without it, the animation spans the full 0%–100% range. Accepts phase keywords (entry, exit, cover, contain) with optional percentage offsets.

/* Only animate while the element is entering the viewport */
.card {
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

/* Animate across the full visible window */
.sticky-bg {
  animation-timeline: view();
  animation-range: cover 0% cover 100%;
}

entry spans from the element's leading edge entering the scrollport to the element being fully inside. cover runs from first pixel visible to last pixel visible. exit mirrors entry on the way out.

Browser Support for CSS Scroll Animations

Not yet Baseline. Chromium and Safari ship it by default; Firefox is the remaining holdout. See the full compatibility matrix on Can I Use.

Safari 26 added full support for animation-timeline, scroll(), view(), and animation-range. Since all iOS browsers use WebKit, this covers mobile Safari, Chrome on iOS, and every other iOS browser.

Firefox has an implementation in Nightly builds behind layout.css.scroll-driven-animations.enabled in about:config, but it hasn't shipped in the release channel. Mozilla's standards position is positive, and the feature is part of Interop 2026. Some sub-features like timeline-scope remain incomplete even in Nightly.

In practice, scroll-driven animations reach roughly 85–90% of global users today. Firefox users need a fallback.

Fallbacks for Older Browsers

With Firefox still lacking default support, production sites need a fallback. The cleanest approach is progressive enhancement: a static, usable layout by default, with scroll animations layered on via @supports.

Feature Detection with @supports

Test for animation-range alongside animation-timeline. Firefox Nightly recognizes animation-timeline but lacks full animation-range support, so a combined check avoids partial implementations:

/* Base: elements are visible and static */
.card {
  opacity: 1;
  transform: none;
}

/* Enhanced: scroll-driven animation only if fully supported */
@supports ((animation-timeline: view()) and (animation-range: 0% 100%)) {
  .card {
    animation: reveal linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 100%;
  }
  @keyframes reveal {
    from { opacity: 0; transform: translateY(40px); }
    to   { opacity: 1; transform: translateY(0); }
  }
}

Intersection Observer as a JavaScript Fallback

For viewport-entrance effects, Intersection Observer is the standard JS alternative: asynchronous, off-main-thread, and universally supported:

// Only run fallback when native support is missing
if (!CSS.supports('animation-timeline', 'view()')) {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach((entry) => {
      entry.target.classList.toggle('in-view', entry.isIntersecting);
    });
  }, { threshold: 0.3 });

  document.querySelectorAll('[data-scroll]')
    .forEach((el) => observer.observe(el));
}

Then add transition-based fallback styles that activate when the .in-view class is toggled:

/* Fallback: transition-based animation */
[data-scroll] {
  opacity: 0;
  transform: translateY(20px);
  transition: opacity .6s ease, transform .6s ease;
}
[data-scroll].in-view {
  opacity: 1;
  transform: translateY(0);
}

/* Override fallback when native scroll-driven animations are supported */
@supports ((animation-timeline: view()) and (animation-range: 0% 100%)) {
  [data-scroll] {
    opacity: 1;
    transform: none;
    transition: none;
  }
}

The scroll-timeline Polyfill

The flackr/scroll-timeline polyfill patches animation-timeline, animation-range, scroll-timeline, and view-timeline in unsupported browsers. It detects native support and skips itself when not needed. The trade-off is JS weight and no compositor-thread performance.

For most production use, @supports + Intersection Observer is lighter and more predictable. The polyfill makes more sense when you need exact spec behavior everywhere.

Accessibility and Reduced Motion

WCAG 2.3.3 (Animation from Interactions) requires that non-essential motion triggered by scrolling can be disabled. Scroll-driven animations, particularly parallax, scale, and 3D transforms, can cause vestibular discomfort.

The recommended pattern is no-motion-first: elements render in their final, static state by default, and scroll animations activate only when the user hasn't requested reduced motion.

Double-Gated Pattern

Nest animation-timeline inside both a motion preference check and a feature support check:

/* Default: static, fully visible layout */
.card {
  opacity: 1;
  transform: none;
}

/* Animation only when user allows motion AND browser supports it */
@media (prefers-reduced-motion: no-preference) {
  @supports ((animation-timeline: view()) and (animation-range: 0% 100%)) {
    .card {
      animation: fade-up linear both;
      animation-timeline: view();
      animation-range: entry 0% entry 100%;
    }
    @keyframes fade-up {
      from { opacity: 0; transform: translateY(40px); }
      to   { opacity: 1; transform: translateY(0); }
    }
  }
}

What Counts as "Motion"

WCAG defines motion animation as spatial movement or size changes. translate, scale, rotate, parallax, and 3D transforms all qualify. Opacity fades and color transitions do not; they're safe alternatives under reduced motion.

Options when reduced motion is active:

• Large spatial animations (parallax, slide-ins, scale, rotate): remove animation-timeline entirely
• Functional animations (reading progress bars, state indicators): keep the timeline but simplify keyframes to opacity or color only
• Simple opacity fades: acceptable to keep since they don't qualify as motion under WCAG

Avoid animation: none !important

A blanket * { animation: none !important } under prefers-reduced-motion: reduce prevents per-element tailoring and causes layout jumps when animations that position elements are abruptly killed. Handle reduced-motion per element instead, keeping content visible at its final state.

Parallax Scroll Effects

Parallax makes background layers move at a different speed than foreground content, creating depth. CSS animation-timeline: scroll() makes multi-layer parallax possible without JavaScript, and each layer gets a different translateY range in its keyframes.

The key: background elements use a small translation range (e.g. translateY(-20%)) while foreground elements use a larger one (translateY(-50%)). Both animations run from 0% to 100% scroll progress; the difference in range creates the depth illusion.

/* Background layer: moves slowly */
.parallax-bg {
  animation: parallaxSlow linear both;
  animation-timeline: scroll(root block);
}
@keyframes parallaxSlow {
  from { transform: translateY(0); }
  to   { transform: translateY(-20%); }
}

/* Foreground layer: moves faster */
.parallax-fg {
  animation: parallaxFast linear both;
  animation-timeline: scroll(root block);
}
@keyframes parallaxFast {
  from { transform: translateY(0); }
  to   { transform: translateY(-50%); }
}

Try the dedicated Parallax generator with configurable speed, depth layers, and blur:

FAQ