How do you programmatically sync CSS animation progress to scroll?

What's really being asked

The interviewer wants to know if you are aware of the CSS scroll-driven animations module and the Web Animations API, or if you still rely on legacy main-thread techniques. At the senior level, they care about performance architecture, compositor-friendly animation, and knowing when to use declarative CSS versus imperative JavaScript. This question separates candidates who read specs from those who only copy Stack Overflow snippets.

The full answer

First, the declarative CSS path: using animation-timeline with the scroll function or a named scroll-timeline to attach keyframes to a scroll container so the browser drives the animation on the compositor without JavaScript. Second, the imperative JS path: using the Web Animations API to create an animation with a ScrollTimeline instance, which lets you control playback rate, pause, or seek programmatically while still keeping the work off the main thread. Third, mention animation-range or animation-range-start and animation-range-end to limit when the animation applies within the scroll span. Fourth, note that view-timeline and ViewTimeline exist for element-based visibility progress, not just container scrolling. Fifth, acknowledge progressive enhancement or feature detection because support is not universal across all browsers.

The mistakes people make

The biggest red flag is describing a requestAnimationFrame loop that reads window scrollY or element scrollTop on every frame and then mutates element style transform or opacity directly. This approach thrashes layout, runs on the main thread, and ignores the modern primitives the browser now provides. Another weak answer is mentioning only CSS transitions and trying to trigger them with class toggles on scroll events, which is still event-driven and not truly synced to scroll progress. Finally, confusing scroll-timeline with the older scroll-behavior property shows a lack of depth.

What usually comes next

The interviewer might ask how you would polyfill or gracefully degrade for browsers without scroll-driven animation support. They could ask about the difference between a scroll progress timeline and a view progress timeline, or when you would choose CSS scroll-timeline over the Web Animations API. They may also probe performance: what happens if you animate layout properties like width or top instead of transform, or how you avoid forced synchronous layout when combining JS and scroll. Another follow-up is how to handle bidirectional scrolling or nested scroll containers with multiple named timelines.

A concrete example

Imagine a product page where a sticky section heading scales down as the user scrolls through a long list. In CSS, you would define scroll-timeline: --section-scroll on the container, then on the heading set animation-timeline: --section-scroll, animation: scale-down linear, and animation-range: contain 0% contain 100%. In JavaScript, you could instead create the same effect by calling heading.animate with a KeyframeEffect that scales from 1 to 0.8, passing a new ScrollTimeline source set to the container and axis set to block. This gives you an animation object you can pause, reverse, or adjust playbackRate based on user interaction while the browser handles the scroll linkage.