A API View Transition é um divisor de águas para o desenvolvimento da Web. Não importa se o site tem uma ou várias páginas, essa API avançada permite criar transições perfeitas entre visualizações, resultando em experiências semelhantes a nativas que cativam os usuários. Disponível atualmente no Chrome, com as mesmas transições de visualização de documentos em breve disponíveis no Safari.
Com cada vez mais pessoas começando a usar a API View Transition, é hora de desmascarar alguns equívocos.
Equívoco 1: a API View Transition faz capturas de tela
Ao executar uma transição de visualização, a API cria snapshots do estado antigo e novo do 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, demonstrações como esta funcionam: o vídeo extraído do novo resumo permanece em reprodução enquanto a transição de visualização ocorre.
A lógica e o CSS usados para isso estão detalhados em nossa documentação.
Equívoco 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. Ao capturar 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 só pode 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. Você vai perceber que a transição em andamento vai para o final quando uma nova é iniciada.
Conceito errado 3: não é possível implementar transições de visualização devido ao suporte do navegador
Muitos desenvolvedores estão preocupados que não possam implementar transições de visualização porque só é compatível com o Chrome. A boa notícia é que o Safari está trabalhando nisso e será incluído na versão futura do Safari 18.
Mas não deixe que o suporte a navegadores instáveis impeça você de implementar transições de visualização ainda hoje. 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 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());
}
Caso seu navegador seja compatível com as transições de visualização de um mesmo documento, você terá a versão aprimorada e animada. Se o navegador não aceitar, você terá a experiência atual. Com o tempo, à medida que mais navegadores oferecem suporte a transições de visualização, mais usuários poderão aproveitar essa versão aprimorada automaticamente.
O mesmo se aplica às transições de visualização entre documentos. Os navegadores que não oferecem suporte a elas ignorarão a ativação do CSS ao analisar as folhas de estilo.
Essa abordagem foi implementada com sucesso no e-commerce, conforme detalhado neste estudo de caso.
Conceito errado 4: as transições de visualização interrompem a renderização incremental
Há declaraçõ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 ocorre depois de carregar todas as folhas de estilo no <head>, analisar todo o JavaScript que bloqueia a renderização no <head> e carregar marcações suficientes. As transições de visualização entre documentos não mudam isso: o conteúdo necessário para First Contentful Paint não muda. Após essa primeira renderização, o navegador pode renderizar de forma incremental o conteúdo recém-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 isso, use esta tag de link:
<link rel="expect" blocking="render" href="#elementId">
Isso substitui a heurística do navegador usada para decidir quando realizar sua primeira renderização: a primeira renderização é atrasada até que o elemento especificado esteja presente na árvore DOM.
Esse bloqueio manual tem algumas proteções integradas. Por exemplo, quando a tag de fechamento </html> é vista, mas o elemento de bloqueio não era, 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 ativamente e avaliar o impacto que ele tem sobre os usuários, medindo o impacto nas suas métricas de performance.
Conceito equivocado 5: o processo de criação de snapshots é lento ou caro
Enquanto a API View Transition prepara a nova visualização e recebe seus snapshots, a visualização antiga permanece visível para o usuário. Por isso, o usuário vê a página antiga por um pouco mais de tempo do que sem as transições de visualização. Esse atraso é insignificante, na realidade, são poucos os frames. No Chrome, o impacto de pageswap, por exemplo, é no máximo dois frames desatualizados: um para executar a lógica e um frame extra para garantir que os snapshots sejam 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
Ao falar sobre transições de visualização, as pessoas costumam consultar a "API View Transitions". Incorreto. A API é chamada de "API View Transition". Observe a "Transition" no singular.
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 (uma) API View Transition para criar (uma ou mais) transições de visualização.