Scroll animation is the effect people most often ask an AI builder for and most often fail to get. The output looks fine until you scroll — then nothing moves, or everything moves at once.
The problem is almost never the model. It is that "make it scroll-animated" describes a feeling, not a mechanism.
Name the mechanism, not the vibe
An AI builder writes code. It needs to know which technique to reach for. There are only a few, and they behave very differently:
- Scroll-linked transforms — an element's position or scale is a direct function of scroll offset. Smooth, reversible, cheap. This is what most people actually mean.
- Scroll-triggered reveals — an element animates once when it enters the viewport, then stays. Good for text and cards, wrong for parallax.
- Pinned sections — the section sticks while inner content advances. This is what produces the "story unfolds as you scroll" feel, and it is the one that most often comes out broken because it needs an explicit scroll distance.
- Progress-driven media — a video or sprite sequence whose current frame is tied to scroll position. Heavy, and rarely worth it.
Say which one you want. "Pin the hero for two viewport heights while the headline scales from 1 to 1.4 and the background image fades out" is a spec. "Make the hero scroll-animated" is not.
Give it a coordinate system
Animation prompts fail on ambiguity about what changes, from what, to what, over what range. Four values, every time:
- The property (
translateY,opacity,scale) - The start value
- The end value
- The scroll range it maps to
If you leave any of the four out, the model picks one, and its pick is usually a default that looks like every other AI-generated page.
Say what must not move
This is the instruction almost nobody includes, and it is the one that separates a usable result from a mess. Navigation, footers, and form fields should generally be exempt. Adding "the nav and any form inputs stay static and fully opaque throughout" removes a whole class of bugs where inputs fade to 40% opacity and stop being readable.
Ask for the reduced-motion branch up front
prefers-reduced-motion: reduce is a real setting that real visitors have on. If you do not ask for it, you will not get it, and adding it later means unpicking the animation code.
Add one line: "Under prefers-reduced-motion: reduce, disable all scroll-linked animation and render every element in its final state." The final state matters — a naive implementation disables the animation and leaves everything at opacity 0.
A worked prompt skeleton
Build a landing page hero with a pinned scroll section. Pin the hero for 200vh of scroll distance. Over that range: the headline scales from 1 to 1.35 and its opacity goes 1 → 0 between 60% and 100% of the range; the background image translates Y from 0 to -15% and blurs from 0 to 8px. The navigation stays fixed, static, and fully opaque throughout. Under
prefers-reduced-motion: reduce, disable all of the above and render the headline at scale 1, opacity 1, with the background unblurred. Use CSS scroll-driven animations where supported, and fall back to an IntersectionObserver-based implementation otherwise. No animation library.
That last line matters too. If you do not specify the implementation, you may get a 40 KB dependency for one effect.
Why the last constraint is worth keeping
Animation libraries are not bad. But an AI builder reaching for one by default means every page you generate carries the same runtime, and you will not notice until you measure. Naming the technique — CSS scroll-driven animations, IntersectionObserver, a library, whichever — keeps that decision yours.
Every prompt in our library is written this way: the mechanism named, the values given, the exempt elements listed, the reduced-motion branch included. That is most of the difference between a prompt that produces a finished section and one that produces a starting point.
Browse the free prompts — no account needed.