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