Scroll-driven animations في CSS: حركة مع السكرول من غير جافاسكريبتCSS scroll-driven animations: scroll motion without JavaScript

Scroll-driven animations are a CSS feature that makes any @keyframes progress with scroll instead of with time. You write the animation as usual and add one line: animation-timeline. No JavaScript, no library, no scroll listener. The animation runs off the main thread, so it stays smooth even when the page is busy.

The idea: time becomes scroll

A normal CSS animation has a timeline: it starts at 0% and ends at 100% after a duration. This feature swaps that timeline for something else:

• scroll(): progress is your scroll position. Top of the page is 0%, the bottom is 100%.
• view(): progress is the element’s own position in the viewport. It is 0% as it starts entering and 100% once it has fully left.

The first is for things tied to the whole page. The second is for things tied to one element.

Example 1: a reading progress bar

.progress {
  position: fixed;
  inset: 0 0 auto 0;
  height: 4px;
  background: #416EDD;
  transform-origin: 0 50%;
  animation: grow linear both;
  animation-timeline: scroll(root);
}

@keyframes grow {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

That is all it takes. Three notes:

• linear matters. Any other easing makes the bar run ahead of or behind the scroll.
• There is no animation-duration. Duration is meaningless here because scroll drives it.
• On an Arabic page, use transform-origin: 100% 50% so the bar starts from the right.

Example 2: an element appearing as it enters

.card {
  animation: rise linear both;
  animation-timeline: view();
  animation-range: entry 0% cover 40%;
}

@keyframes rise {
  from { opacity: 0; transform: translateY(40px); }
  to   { opacity: 1; transform: none; }
}

Each card animates on its own according to its own position. No IntersectionObserver and no class being added.

animation-range: where it starts and ends

This is the confusing part at first. With view() there are named phases:

• entry: from the element’s edge entering the viewport until it is fully in.
• exit: from when it starts leaving until it is gone.
• cover: the whole journey, first pixel in to last pixel out.
• contain: the period when the element is fully inside the viewport.

So entry 0% cover 40% means: start when the element touches the viewport, finish when it has covered 40% of its journey. For an exit animation too:

.card {
  animation: rise linear both, fade linear both;
  animation-timeline: view(), view();
  animation-range: entry 0% entry 100%, exit 0% exit 100%;
}

@keyframes fade { to { opacity: 0; } }

Browser support and the fallback

The feature has been in Chrome and Edge for a while and reached Safari in recent versions. Check Firefox support on caniuse before relying on it, since it is changing.

The safe way is to write the animation as an extra inside @supports, with the element plainly visible without it:

@supports (animation-timeline: view()) {
  @media (prefers-reduced-motion: no-preference) {
    .card {
      animation: rise linear both;
      animation-timeline: view();
      animation-range: entry 0% cover 40%;
    }
  }
}

A browser without support shows the card still and visible. So does a user with reduced motion on. That matters more than any animation: content shows even when motion fails.

When it is enough and when you need GSAP

CSS is enough when:

• The motion is simple: reveal, shift, progress bar, light parallax.
• Each element animates on its own.
• You want the least code and the best performance.

GSAP with ScrollTrigger is still needed when:

• Pinning a section while motion plays inside it. CSS gets close with position: sticky, but control is limited.
• Complex sequencing: a timeline with ten overlapping steps in precise order.
• Events: running code when a section enters or leaves, not only animating a property.
• Smoothed scrub: motion that lags slightly behind the scroll and catches up.
• Computed values: motion that depends on sizes calculated in JavaScript.
• Guaranteed support in every browser without thinking about it.

Start with CSS. When you find yourself working around it, bring in the library.

Common mistakes

• Forgetting both. Without animation-fill-mode: both the element snaps back to its original look before and after the range.
• Property order. The animation shorthand resets animation-timeline. Always write animation-timeline after it.
• Animating expensive properties. Stay with transform and opacity. Animating width or top brings the work back to the main thread.
• overflow: hidden on an ancestor. It makes that ancestor the scroll container, so view() is measured against it, not the page. Use overflow: clip if you only want clipping.
• Motion on everything. A page where every element rises from below is tiring. Choose what deserves it.

Want more motion without libraries? See View Transitions API: a dark mode switch that grows as a circle. And to learn GSAP and ScrollTrigger for the cases CSS does not cover, that is in the GSAP web animation course.