Firefox 159 вышел: анимации по скроллу на чистом CSS теперь работают во всех основных браузерах
27 октября Mozilla выпустила Firefox 159, и в нём по умолчанию включены scroll-driven animations — анимации, которые идут не по времени, а по прокрутке страницы. Chrome поддерживает их с 2023 года, Safari — с версии 26.0. Теперь эффект, ради которого раньше подключали JavaScript-библиотеки, можно закладывать в макет как обычное CSS-поведение. Разбираем, что это меняет для дизайнеров.

В заметках к релизу Firefox 159 на MDN scroll-driven animations перечислены первой строкой раздела CSS: функция включена по умолчанию, анимации можно привязать к временной шкале прокрутки вместо обычной временной. Поддержка в Safari описана в обзоре WebKit к Safari 26.0, в Chrome — в документации Chrome for Developers, где функция доступна с версии 115. Firefox был последним из трёх движков, кто её не включал.
Для продуктовых команд это меняет статус целого класса эффектов. Индикатор прочтения, проявление блоков при появлении в кадре, «липкая» шапка, которая сжимается при скролле, параллакс в промо-разделе — раньше всё это держалось на обработчиках прокрутки в JavaScript, нагружало основной поток и часто дёргалось на слабых телефонах. Теперь это декларативное CSS-свойство, которое браузер может считать вне основного потока.
Значит, анимация по скроллу переходит из разряда «если разработчик успеет» в разряд нормальной части спецификации интерфейса — особенно в сложных продуктах, где ею показывают прогресс заполнения, шаги онбординга или загрузку данных. Если такой продукт делает подрядчик, стоит сразу обсудить, умеет ли он это поддерживать: команде, которая проектирует и собирает веб-приложения, легче вести анимации на CSS как часть дизайн-системы, чем поддерживать отдельный скрипт.
Что именно вышло?
Спецификация Scroll-driven Animations рабочей группы CSS в W3C вводит два типа временных шкал:
scroll()— прогресс анимации равен прогрессу прокрутки контейнера или всей страницы: доскроллили до середины — анимация на 50%;view()— прогресс зависит от того, насколько элемент вошёл в видимую область и вышел из неё.
Шкала подключается свойством animation-timeline, а участок, на котором анимация проигрывается, задаётся через animation-range — например, «от момента, когда карточка показалась снизу, до момента, когда она заняла весь экран». Обычные ключевые кадры @keyframes при этом не меняются, поэтому существующие анимации можно перевести на прокрутку без переделки.
Попутно в том же релизе Mozilla убрала старый экспериментальный синтаксис masonry-раскладки: его заменяет новое значение display: grid-lanes. Тем, кто проектирует плиточные галереи, стоит перепроверить макеты, если разработчики опирались на прежний вариант.
Что можно делать без JavaScript?
Типовые сценарии, которые теперь закрываются CSS:
- полоска прогресса чтения статьи вверху экрана;
- плавное проявление карточек, графиков и иллюстраций при прокрутке;
- сжатие шапки и смена её фона после первого экрана;
- подсветка активного пункта оглавления или шага в длинной форме;
- параллакс и смена слоёв в промо-блоках и сторителлинге.
Сложная логика — анимации, зависящие от данных, жестов или скорости прокрутки — по-прежнему требует скрипта. Но базовые эффекты больше не тянут за собой библиотеку и не мешают скорости загрузки страницы.
Как описать анимацию в макете?
Главная ошибка при передаче таких эффектов — показать в прототипе красивый ролик и не объяснить, к чему он привязан. Для каждой анимации по скроллу в спецификации нужны четыре вещи: какая шкала (вся страница или конкретный контейнер), начальная и конечная точка участка прокрутки, какие свойства меняются и что пользователь видит без анимации. Подробно о том, как собирать такие аннотации, мы писали в разборе передачи дизайна в разработку, а о длительностях, кривых и смысле движения — в материале о моушн-дизайне в интерфейсе.
Анимируйте по возможности прозрачность и трансформации: их браузер отрисовывает дешевле всего. Изменение размеров и отступов при прокрутке заставляет пересчитывать раскладку и сводит выигрыш на нет.
Доступность и reduced motion
Анимация, привязанная к скроллу, срабатывает на каждое движение пальца, поэтому для людей с вестибулярными нарушениями она тяжелее обычной. Критерий 2.3.3 WCAG 2.2 «Анимация от взаимодействий» требует возможности отключить движение, вызванное действиями пользователя, если оно не необходимо. На практике это значит: в макете должно быть состояние для настройки «уменьшить движение» (prefers-reduced-motion), в котором контент сразу виден и ничего не едет. Общие требования к контрасту и фокусу мы собирали в статье о WCAG 2.2.
Что сделать команде сейчас?
- Составьте список эффектов, которые сейчас держатся на скриптах прокрутки, и отметьте, какие из них покрывают
scroll()иview(). - Добавьте в шаблон спецификации поле «привязка к прокрутке» с началом и концом участка.
- Для каждого эффекта нарисуйте статичный вариант для reduced motion.
- Проверьте новые эффекты на слабом Android-смартфоне: декларативная анимация быстрее, но тяжёлые свойства всё равно тормозят.
- Учтите, что часть пользователей ещё неделями будет сидеть на старых версиях Firefox: интерфейс без анимации должен оставаться полностью рабочим.

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.


