Firefox 159 вышел: анимации по скроллу на чистом CSS теперь работают во всех основных браузерах

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

Редакция Флагштока27 октября 20265 мин чтения
Интерфейсные карточки, выстроенные вдоль траектории прокрутки на столе дизайнера

В заметках к релизу 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:

  • полоска прогресса чтения статьи вверху экрана;
  • плавное проявление карточек, графиков и иллюстраций при прокрутке;
  • сжатие шапки и смена её фона после первого экрана;
  • подсветка активного пункта оглавления или шага в длинной форме;
  • параллакс и смена слоёв в промо-блоках и сторителлинге.

Сложная логика — анимации, зависящие от данных, жестов или скорости прокрутки — по-прежнему требует скрипта. Но базовые эффекты больше не тянут за собой библиотеку и не мешают скорости загрузки страницы.

Анимация по скроллу не зависит от времени. В макете её описывают не длительностью в миллисекундах, а участком прокрутки: «начинается, когда блок на 20% в кадре, заканчивается, когда он на 60%».

Как описать анимацию в макете?

Главная ошибка при передаче таких эффектов — показать в прототипе красивый ролик и не объяснить, к чему он привязан. Для каждой анимации по скроллу в спецификации нужны четыре вещи: какая шкала (вся страница или конкретный контейнер), начальная и конечная точка участка прокрутки, какие свойства меняются и что пользователь видит без анимации. Подробно о том, как собирать такие аннотации, мы писали в разборе передачи дизайна в разработку, а о длительностях, кривых и смысле движения — в материале о моушн-дизайне в интерфейсе.

Анимируйте по возможности прозрачность и трансформации: их браузер отрисовывает дешевле всего. Изменение размеров и отступов при прокрутке заставляет пересчитывать раскладку и сводит выигрыш на нет.

Доступность и reduced motion

Анимация, привязанная к скроллу, срабатывает на каждое движение пальца, поэтому для людей с вестибулярными нарушениями она тяжелее обычной. Критерий 2.3.3 WCAG 2.2 «Анимация от взаимодействий» требует возможности отключить движение, вызванное действиями пользователя, если оно не необходимо. На практике это значит: в макете должно быть состояние для настройки «уменьшить движение» (prefers-reduced-motion), в котором контент сразу виден и ничего не едет. Общие требования к контрасту и фокусу мы собирали в статье о WCAG 2.2.

Что сделать команде сейчас?

  1. Составьте список эффектов, которые сейчас держатся на скриптах прокрутки, и отметьте, какие из них покрывают scroll() и view().
  2. Добавьте в шаблон спецификации поле «привязка к прокрутке» с началом и концом участка.
  3. Для каждого эффекта нарисуйте статичный вариант для reduced motion.
  4. Проверьте новые эффекты на слабом Android-смартфоне: декларативная анимация быстрее, но тяжёлые свойства всё равно тормозят.
  5. Учтите, что часть пользователей ещё неделями будет сидеть на старых версиях Firefox: интерфейс без анимации должен оставаться полностью рабочим.
Редакция Флагштока

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