Заблуждения о переходах между видами

Брамус

View Transition API меняет правила игры в веб-разработке. Независимо от того, является ли ваш веб-сайт одностраничным или многостраничным, этот мощный API позволяет создавать плавные переходы между представлениями, что приводит к созданию естественного опыта, который очаровывает пользователей. В настоящее время доступно в Chrome, аналогичные переходы между видами документов скоро будут доступны в Safari.

Поскольку все больше и больше людей начинают изучать API View Transition, пришло время развенчать некоторые заблуждения.

Заблуждение 1: View Transition API делает снимки экрана

При запуске перехода представления API делает снимки старого и нового состояния контента. Эти снимки затем анимируются, как подробно описано в разделе документации «Как работают эти переходы» .

Хотя вы можете использовать термин «скриншот» для обозначения старого снимка, новый снимок — это не снимок экрана, а реальное представление узла. Думайте об этом как о замененном элементе.

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root) 👈 Screenshot
      └─ ::view-transition-new(root) 👈 Live representation

Благодаря этому живому аспекту такие демонстрации работают: видео, полученное из нового снимка, продолжает воспроизводиться, пока происходит переход между видами.

Воспроизводящееся видео, участвующее в переходе просмотра. Минимальная демонстрация . Источник .

Используемая для этого логика и CSS подробно описаны в нашей документации .

Заблуждение 2. Захват более одного элемента приводит к выполнению нескольких переходов между представлениями.

Когда вы захватываете несколько элементов, процесс создания снимков фиксирует все старые и новые состояния. Когда вы захватываете .box в дополнение к элементу :root , вы получаете вот такое псевдодерево:

::view-transition
└─ ::view-transition-group(root)
|  └─ ::view-transition-image-pair(root)
|     ├─ ::view-transition-old(root)
|     └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
   └─ ::view-transition-image-pair(box)
      ├─ ::view-transition-old(box)
      └─ ::view-transition-new(box)

Хотя это дерево содержит несколько пар снимков, выполняется только один переход представления.

В настоящее время Chrome ограничен одновременным запуском одного перехода представления для каждого документа. Попробуйте быстро щелкнуть по этой демонстрации , чтобы начать новый переход вида. Вы заметите, что текущий переход пропускается до конца, когда начинается новый.

Заблуждение 3. Вы не можете реализовать переходы между представлениями из-за поддержки браузера.

Многие разработчики обеспокоены тем, что они не могут реализовать переходы между представлениями, поскольку они поддерживаются только в Chrome. Хорошая новость заключается в том, что Safari работает над этим и включит его в предстоящий выпуск Safari 18 .

Но, тем не менее, не позволяйте нестабильной поддержке браузера помешать вам реализовать переходы представлений сегодня. Переходы между видами — идеальный материал для прогрессивного улучшения . В исходной документации описан метод добавления этой методологии в ваш код.

function handleClick(e) {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
        updateTheDOMSomehow();
        return;
    }

    // With a View Transition:
    document.startViewTransition(() => updateTheDOMSomehow());
}

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

То же самое относится и к переходам между представлениями между документами . Браузеры, которые их не поддерживают, будут игнорировать поддержку CSS при анализе таблиц стилей.

Этот подход был успешно реализован в электронной коммерции, как подробно описано в этом тематическом исследовании.

Заблуждение 4. Переходы между видами нарушают инкрементальный рендеринг.

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

Браузеры начинают отображать страницу, когда у них «достаточно» контента. В большинстве браузеров это происходит после загрузки всех таблиц стилей в <head> , анализа всего блокирующего рендеринг JavaScript в <head> и загрузки достаточного количества разметки. Переходы между представлениями между документами этого не меняют: содержимое, необходимое для первой контентной отрисовки, не изменяется. После этого первого рендеринга браузер может — и будет — постепенно отображать вновь полученный контент.

Вы можете заблокировать рендеринг до тех пор, пока в DOM не появится определенный элемент. Это удобно в ситуациях, когда вы хотите быть уверены, что элементы, участвующие в переходе вида, присутствуют на новой странице.

Для этого используйте этот тег ссылки:

<link rel="expect" blocking="render" href="#elementId">

Это переопределяет эвристику браузера, используемую для принятия решения о том, когда выполнять первый рендеринг: первый рендеринг задерживается до тех пор, пока указанный элемент не появится в дереве DOM.

В эту ручную блокировку встроены некоторые меры безопасности. Например, если закрывающий тег </html> виден, а блокирующий элемент — нет, рендеринг больше не будет блокироваться. Кроме того, вы можете добавить свою собственную логику тайм-аута, которая удаляет атрибут блокировки в любой момент времени.

Очевидно, что блокировку рендеринга следует использовать с осторожностью. Влияние блокировки рендеринга необходимо оценивать в каждом конкретном случае. По умолчанию избегайте использования blocking=render если только вы не можете активно измерять и измерять влияние, которое оно оказывает на ваших пользователей, путем измерения влияния на ваши показатели производительности .

Заблуждение 5: процесс создания снимков медленный или дорогостоящий

Пока API перехода представления подготавливает новое представление и получает его снимки, старое представление остается видимым для пользователя. Из-за этого пользователь может видеть старую страницу немного дольше, чем без переходов просмотра. Однако эта задержка незначительна, на самом деле всего несколько кадров. Например, в Chrome эффект подкачки pageswap составляет максимум два устаревших фрейма: один для выполнения логики плюс один дополнительный фрейм для обеспечения компоновки и кэширования снимков.

Более того, данные для снимков берутся непосредственно из компоновщика, поэтому для получения данных снимка не требуется никаких дополнительных действий по компоновке или перерисовке.

Бонусное заблуждение: это API View Transitions

Говоря о переходах представлений, люди часто ссылаются на «API переходов представлений». Это неверно. API называется «View Transition API» — обратите внимание на единственное слово «Transition».

Заблуждение возникает из-за того, что в некоторых статьях (в том числе в нашей собственной документации по DCC) используется неверный термин.

Чтобы запомнить правильное имя, нужно использовать (один) View Transition API для создания (одного или нескольких) переходов представлений.