CSS Scroll-driven animation timelines 正在把一种常见前端效果从 JavaScript 逻辑里挪回 CSS：视差滚动。开发者现在可以用 view-timeline-name 创建 view progress timeline，让元素穿过视口的进度直接驱动动画，而不必再用滚动事件监听器反复计算位移。

这件事重要的地方不在于网页又多了一种动效写法，而在于它把“按帧改位置”的工程问题，改写成一段可复用的声明式样式。对维护设计系统、组件库和营销页面的团队来说，这意味着更少的脚本、更清楚的职责边界。但它并不等于所有滚动动效都该迁到 CSS，也不能简单宣称已在所有浏览器完整可用。

CSS 时间轴把视差从脚本计算变成样式规则

传统视差效果通常依赖 JavaScript：监听 scroll，读取元素位置，再在每一帧更新 transform。这个路线灵活，但容易把视觉效果和业务脚本缠在一起，也容易引出主线程压力、节流、防抖和滚动同步问题。

CSS Scroll-driven animations 的做法不同。view-timeline-name: --parallax-tl 会为容器创建一个 view progress timeline：当元素开始进入视口时进度接近 0%，完全离开视口时进度到 100%。view-timeline-axis: block 则指定沿块轴追踪，在常见横排页面里就是垂直方向。

子元素再用 animation-timeline: --parallax-tl 把动画时钟从“秒”切换成“滚动进度”。这里有一个容易踩坑的细节：animation-timeline 不是 animation 简写的一部分，必须单独声明，而且要放在 animation 简写之后；否则简写会把未包含的长属性重置回初始值。

项目传统 JavaScript 视差CSS 原生视差
驱动方式scroll 监听与逐帧计算view progress timeline
复用形态函数、库或组件逻辑工具类和样式变量
工程风险主线程占用、同步复杂兼容性与 CSS 细节约束
适用判断高度定制交互更灵活标准视差背景更合适

MDN 已将 Scroll-driven animation timelines 作为 CSS 指南介绍，Chrome Developer 文档也给出滚动驱动动画示例。这说明它不再只是草案里的概念功能，但工程团队仍应按目标浏览器矩阵逐项验证，而不是把“可用”理解成“无条件可上生产”。

位移、缩放和裁切共同解决空白问题

原文方案的核心参数是 --parallax-offset，默认值为 20。它让子元素从 translate: 0 -20% 移动到 translate: 0 20%。容器和内部图片移动速度不同，视觉上就产生深度感。

问题也由此出现：如果子元素和容器一样高，向上或向下移动都会露出空白边。解决办法是同步放大子元素。默认 --parallax-offset: 20 时，缩放公式会把子元素放大到 140%，也就是上下各预留 20% 的移动余量。

overflow: hidden 在这里不是装饰，而是必要的裁切。它负责把放大后的子元素限制在容器盒子内，避免用户看到超出的边缘。一个变量同时控制位移和缩放，团队调强或调弱视差时，不必再手工计算安全边界。

这也是 CSS 方案最实用的部分：它更像一个可塞进设计系统的 utility class。做活动页、品牌页、图文专题时，设计师要求“背景慢一点动”，前端不必再引入一个视差库，或者在 React、Vue 组件里增加滚动状态。

性能预期不能替代无障碍和兼容性检查

CSS 滚动驱动动画有机会让浏览器更好地调度动画，部分实现可以避开主线程上的脚本计算。这个方向对性能友好，但目前不能把它写成“已量化优于 JavaScript”。真实表现仍取决于浏览器实现、页面结构、图片尺寸、合成层数量和设备性能。

更直接的限制来自无障碍。视差是绑定滚动的运动，对部分用户会造成不适。方案中应使用 prefers-reduced-motion: reduce 关闭动画，并把缩放恢复为 scale: 1。这不是锦上添花，而是上线标准的一部分。

对前端团队而言，接下来最该观察三件事：目标浏览器对 view-timeline-name、animation-timeline、animation-range 的支持是否满足项目要求；设计系统是否需要把视差封装成统一工具类；无障碍测试是否覆盖减少动态效果的系统设置。

这项技术适合替代一部分“背景慢速移动”的视差脚本，不适合被包装成滚动交互的总解法。复杂叙事页面、精确到帧的滚动剧情、跨元素联动和业务状态驱动动画，JavaScript 仍有位置。CSS 这次赢在清爽，不赢在包办一切。