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 для создания (одного или нескольких) переходов представлений.