A API View Transition é um divisor de águas no desenvolvimento da Web. Não importa se o site tem uma ou várias páginas, essa API poderosa permite criar transições perfeitas entre visualizações, resultando em experiências semelhantes às nativas que conquistam os usuários. Atualmente disponível no Chrome, com as mesmas transições de visualização de documentos em breve no Safari.
Com cada vez mais pessoas começando a usar a API View Transition, é hora de desmascarar alguns equívocos.
Conceito errado 1: a API View Transition faz capturas de tela
Ao executar uma transição de visualização, a API faz snapshots do estado antigo e do novo conteúdo. Esses snapshots são animados, conforme detalhado na seção Como essas transições funcionam" da documentação.
Embora seja possível usar o termo "captura de tela" no snapshot antigo, o novo snapshot não é uma captura de tela, mas, na verdade, uma representação ativa do nó. Pense nisso como um elemento substituído.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Graças a esse aspecto ao vivo, demos como esta funcionam: o vídeo, que é originado do novo instantâneo, continua sendo reproduzido enquanto a transição de visualização está acontecendo.
A lógica e o CSS usados para isso estão detalhados em nossa documentação.
Conceito errado 2: capturar mais de um elemento resulta em várias transições de visualização em execução
Quando você captura vários elementos, o processo de captura de snapshot captura todos os estados antigos e novos. Quando você captura um .box além do elemento :root, você recebe esta pseudo-árvore:
::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)
Embora essa árvore contenha vários pares de snapshots, apenas uma transição de visualização é executada.
No momento, o Chrome está limitado a executar uma transição de visualização por documento ao mesmo tempo. Tente clicar rapidamente nesta demonstração para iniciar uma nova transição de visualização. A transição em andamento vai pular para o fim quando uma nova começar.
Conceito errado 3: não é possível implementar transições de visualização devido ao suporte do navegador
Muitos desenvolvedores estão preocupados com a impossibilidade de implementar transições de visualização porque elas só têm suporte no Chrome. A boa notícia é que o Safari está trabalhando nisso e vai incluir essa opção na próxima versão do Safari 18.
No entanto, não deixe que o suporte irregular do navegador impeça a implementação de transições de visualização. As transições de visualização são o material perfeito para o aprimoramento progressivo. A documentação original compartilha um método para adicionar essa metodologia ao seu código.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Se o navegador oferecer suporte a transições de visualização do mesmo documento, você vai receber a versão enriquecida e animada. Se o navegador não tiver, você vai ter a experiência atual. Com o tempo, à medida que mais navegadores oferecem suporte a transições de visualização, mais usuários vão ter acesso a essa versão enriquecida, tudo de forma automática.
O mesmo se aplica às transições de visualização entre documentos. Os navegadores que não forem compatíveis ignorarão a ativação do CSS ao analisar as folhas de estilo.
Essa abordagem foi implementada no e-commerce, conforme detalhado neste estudo de caso.
Concepção equivocada 4: as transições de visualização interrompem a renderização incremental
Há reivindicações de que as transições de visualização interrompem a renderização incremental. Isso não é verdade: as transições de visualização entre documentos foram especificadas para não quebrar esse aspecto fundamental da Web.
Os navegadores começam a renderizar uma página quando têm conteúdo "suficiente". Na maioria dos navegadores, isso acontece depois de carregar todas as folhas de estilo no <head>, analisar todo o JavaScript que bloqueia a renderização no <head> e carregar marcação suficiente. As transições de visualização entre documentos não mudam isso: o conteúdo necessário para First Contentful Paint não muda. Depois dessa primeira renderização, o navegador pode renderizar de forma incremental o conteúdo recebido.
Você pode bloquear a renderização até que um determinado elemento esteja presente no DOM. Isso é conveniente em situações em que você quer ter certeza de que os elementos que participam da transição de visualização estão presentes na nova página.
Para fazer isso, use esta tag de link:
<link rel="expect" blocking="render" href="#elementId">
Isso substitui as heurísticas do navegador usadas para decidir quando realizar a primeira renderização: a primeira renderização é adiada até que o elemento especificado esteja presente na árvore DOM.
Esse bloqueio manual tem algumas salvaguardas integradas. Por exemplo, quando a tag </html> de fechamento é exibida, mas o elemento de bloqueio não, a renderização não é mais bloqueada. Além disso, é possível adicionar sua própria lógica de tempo limite, que remove o atributo de bloqueio a qualquer momento.
O bloqueio de renderização precisa ser usado com cautela. O impacto do bloqueio da renderização precisa ser avaliado caso a caso. Por padrão, evite usar blocking=render, a menos que você possa medir e avaliar ativamente o impacto que ele tem nos usuários, medindo o impacto nas suas métricas de performance.
Conceito errado 5: o processo de criação de snapshots é lento ou caro
Enquanto a API ViewTransition prepara a nova visualização e recebe os snapshots, a antiga permanece visível para o usuário. Por isso, o usuário consegue ver a página antiga por um tempo maior do que sem as transições de visualização. Esse atraso é insignificante, na verdade, apenas alguns frames. No Chrome, o impacto de pageswap, por exemplo, é de no máximo dois frames desatualizados: um para executar a lógica e outro extra para garantir que os snapshots foram compostos e armazenados em cache.
Além disso, os dados dos snapshots são obtidos diretamente do compositor. Portanto, não há etapas extras de layout ou repintura que precisam acontecer para receber os dados do snapshot.
Equívoco bônus: é a API View Transitions
Quando se trata de transições de visualização, as pessoas geralmente se referem à "API View Transitions". Incorreto. A API é chamada de "API de transição de visualização". Observe o singular "Transição".
Esse equívoco ocorre devido ao uso do termo errado em alguns artigos, incluindo em nossos próprios documentos sobre DCC.
O truque para lembrar o nome correto é usar a API View Transition para criar uma ou mais transições de visualização.