Заблуждения о переходах между видами
![](/static/storage/239141734640151887044284571894408726400.png)
View Transition API — это революционный инструмент веб-разработки. Независимо от того, является ли ваш сайт одностраничным или многостраничным, этот мощный API позволяет вам создавать плавные переходы между представлениями, что приводит к нативному опыту, который очаровывает пользователей. В настоящее время доступно в Chrome, а вскоре такие же переходы между представлениями документов будут доступны в Safari.
Поскольку все больше людей начинают изучать API View Transition, пришло время развеять некоторые заблуждения.
Заблуждение 1: API View Transition делает снимки экрана
При запуске перехода представления API делает снимки старого и нового состояния контента. Затем эти снимки анимируются. Хотя вы можете использовать термин скриншот для старого снимка, новый снимок — это не снимок экрана, а на самом деле живое представление узла. Думайте о нем как о замененном элементе.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Благодаря этому аспекту живого воспроизведения такие демонстрации работают, видео, полученное из нового снимка, продолжает воспроизводиться, пока происходит смена вида.
Заблуждение 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 ограничен запуском одного перехода представления на документ одновременно. Попробуйте быстро щелкнуть в этой демонстрации, чтобы начать новый переход представления. Вы заметите, что текущий переход заканчивается, когда начинается новый.
Примечание: В будущем, с помощью переходов на уровне элементов, вы сможете запускать переход на поддереве DOM, а также станет возможным иметь одновременные переходы в одном документе — при условии, что они не будут совместно использовать снимки элементов.
Заблуждение 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 при анализе таблиц стилей.
Примечание: Не забудьте также учесть предпочтения пользователя по уменьшению движения. Это можно сделать в JavaScript или CSS, обернув все эти имена или анимации в @media (prefers-reduced-motion: no-reduce)
условный оператор. Если элементы не были захвачены или нет анимаций для запуска, переход представления заменит старый DOM на новый DOM без выполнения какой-либо анимации.
Заблуждение 4: Переходы между видами нарушают пошаговую визуализацию
Есть утверждения, что переходы между представлениями нарушают инкрементальный рендеринг. Это неправда: переходы между представлениями между документами были определены так, чтобы не нарушать этот фундаментальный аспект веба.
Браузеры начинают рендеринг страницы, когда у них есть «достаточно» контента. Это в большинстве браузеров после загрузки всех таблиц стилей в <head>
, разбора всего JavaScript, блокирующего рендеринг, и загрузки достаточной разметки. Переходы между представлениями документов не меняют этого: контент, необходимый для First Contentful Paint, остается неизменным. После этого первого рендеринга браузер может и будет постепенно рендерить вновь полученный контент.
Вы можете заблокировать рендеринг, пока определенный элемент не будет присутствовать в DOM. Это удобно в ситуациях, когда вы хотите быть уверены, что элементы, участвующие в переходе представления, присутствуют на новой странице.
Для этого используйте этот тег ссылки:
<link rel="expect" blocking="render" href="#elementId">
Это переопределяет эвристику браузера, используемую для определения времени выполнения первого рендеринга: первый рендеринг задерживается до тех пор, пока указанный элемент не появится в дереве DOM.
Эта ручная блокировка имеет некоторые встроенные защитные меры. Например, когда закрывающий тег </html>
виден, а блокирующий элемент — нет, рендеринг больше не будет блокироваться. Кроме того, вы можете добавить собственную логику тайм-аута, которая удаляет блокирующий атрибут в любой момент времени.
Очевидно, что блокировку рендеринга следует использовать с осторожностью. Влияние блокировки рендеринга необходимо оценивать в каждом конкретном случае. По умолчанию избегайте использования blocking=render
, если только вы не можете активно измерить и оценить ее влияние на ваших пользователей, измеряя влияние на ваши показатели производительности.
Заблуждение 5: Процесс создания моментальных снимков медленный и дорогой
Пока View Transition API подготавливает новый вид и получает его снимки, старый вид остается видимым для пользователя. Из-за этого пользователь видит старую страницу немного дольше, чем без переходов видов. Однако эта задержка незначительна, на самом деле всего несколько кадров. В Chrome влияние pageswap
, например, составляет максимум два устаревших кадра: один для выполнения логики плюс один дополнительный кадр для обеспечения того, что снимки были составлены и кэшированы.
Более того, данные для снимков берутся непосредственно из компоновщика, поэтому для получения данных снимка не требуется выполнять дополнительные шаги по компоновке или перерисовке.