Conteúdo deste artigo
- O jeito antigo está morto
- Sua transição morrerá aleatoriamente, e aqui está o porquê
- Por que suas imagens parecem caramelo
- Os dois eventos que unem tudo
- O que vem a seguir
Perdi um sábado inteiro nisso.
Também não é um sábado preguiçoso, mas um daqueles raros e esculpidos sábados do tipo “Finalmente vou construir aquela coisa”. Eu tinha visto as demos de Jake Archibald . Eu assisti à palestra do Chrome Dev Summit. Eu sabia que as transições de visualização entre documentos eram reais, que você poderia obter aquelas transições de página com sensação nativa em sites simples e antigos de várias páginas sem uma única estrutura. Sem reação. Não, Astro. Nenhum roteador do lado do cliente finge que seu aplicativo de várias páginas (MPA) é um aplicativo de página única (SPA). Apenas páginas HTML vinculadas a outras páginas HTML, com o navegador cuidando da animação entre elas. Claro que sim.
Então comecei a construir. E nada funcionou.
O primeiro tutorial que encontrei me fez colocar <meta name="view-transition" content="same-origin"> em meu <head>. Parecia bastante simples. Adicionei-o às duas páginas, cliquei no meu link e… nada. Sem transição. Nenhum erro. Apenas um carregamento de página normal e instantâneo como em 2004. Abri o DevTools, verifiquei minha sintaxe, reiniciei o servidor, experimentei o Chrome Canary, limpei o cache. Nada. Fiz o que qualquer desenvolvedor que se preze faz naquele momento: copiei o código, caractere por caractere, da postagem do blog e colei.
Passei duas horas convencido de que era um idiota.
Acontece que <meta> sintaxe da tag? Obsoleto. Desapareceu. O Chrome o enviou e depois o substituiu por um opt-in baseado em CSS, e metade dos tutoriais da Internet ainda mostram o método antigo. Essas postagens de blog mais antigas ainda têm uma boa classificação. Eles parecem autoritários. E eles estão simplesmente errados agora. Não errado porque os autores foram ruins – errado porque as especificações passaram sob os pés de todos e ninguém voltou para atualizar suas postagens.
A outra metade dos tutoriais que encontrei eram sobre transições de visualização do mesmo documento. Coisas de SPA. document.startViewTransition() chamado em JavaScript quando você mesmo troca o conteúdo do DOM, o que é legal e útil, mas é um recurso completamente diferente quando você realmente se senta para implementá-lo. A superfície da API é diferente. O modelo mental é diferente. As pegadinhas são muito diferentes. E ainda assim, Google “visualize o tutorial de transições” e boa sorte para descobrir sobre qual sabor você está lendo até completar três parágrafos.
Então, se você está aqui, suponho que já tenha passado por alguma versão disso. Você tentou a meta tag. Não funcionou. Você experimentou a API JavaScript em um site real de várias páginas e percebeu que ela só é acionada em um único documento. Talvez você tenha algo meio funcionando em uma demonstração, mas ele desmoronou no segundo em que você adicionou conteúdo real – imagens se esticando de maneira estranha, transições suspensas por segundos sem explicação ou seu arquivo CSS se transformando em 200 linhas de declarações view-transition-name porque você tem uma grade de 40 cartões de produto. Você se culpou. Não foi sua culpa. O ecossistema de documentação em torno desse recurso está uma bagunça no momento e a especificação tem sido um alvo móvel.
Esta é a Parte 1 de uma série de duas partes , e é o artigo que eu gostaria que existisse naquele sábado. Vamos cobrir a maneira atual de ativar @view-transition em CSS (não a meta tag, não JavaScript), em seguida, explore o tempo limite de 4 segundos que matará silenciosamente suas transições em páginas lentas e como depurá-lo, em seguida, corrija o aspecto distorção de proporção que faz com que cada transição de imagem pesada pareça um espelho de casa de diversão e, finalmente, obtenha um controle adequado dos eventos pagereveal e pageswap que fornecem controle programático sobre todo o ciclo de vida.
Na Parte 2, abordaremos o problema de dimensionamento – como lidar com view-transition-name em dezenas ou centenas de elementos sem que sua folha de estilo se torne um desastre, a diferença entre view-transition-name e view-transition-class , padrões de nomenclatura just-in-time e execução prefers-reduced-motion da maneira certa.
Série de transições de visualização entre documentos
- As pegadinhas que ninguém menciona (Você está aqui!)
- Dimensionando transições de visualização em centenas de elementos (Próxima segunda-feira!)
Pegue um café. Talvez uma recarga. Este é denso e não vou perder seu tempo, mas há muito terreno aqui e nada disso é óbvio.
O jeito antigo está morto
<!-- THIS IS DEPRECATED - stop copying this from old tutorials -->
<meta name="view-transition" content="same-origin">/* THIS is the current opt-in - goes in your CSS */
@view-transition {
navigation: auto;
}Aqui está a configuração mínima. Dois arquivos HTML, uma regra CSS em cada um. Observe que, a partir de 2026, as transições de visualização entre documentos são suportadas em navegadores baseados em Chromium e Safari 18.2+. O suporte do Firefox está em andamento enquanto escrevo isto.
É isso. Dois arquivos HTML. Uma regra CSS para cada um. Clique em um link entre eles em um navegador compatível (como o moderno Chromium ou Safari 18.2+) e você obterá um cross-fade suave. Sem JavaScript. Sem metatags. Nenhuma etapa de construção. O navegador tira um instantâneo da página antiga, tira um instantâneo da nova página e faz uma animação entre elas automaticamente.
Agora, por que a especificação mudou de uma meta tag para uma regra CSS? Não foi arbitrário.
A meta tag era um instrumento contundente. Estava ativado ou desativado em toda a página. Você não poderia dizer “habilitar transições no desktop, mas não no celular, onde as animações parecem complicadas em hardware de baixo custo”. Você não poderia aceitar condicionalmente com base nas preferências do usuário. Estava apenas… lá, ou não.
A abordagem CSS abre tudo isso:
/* Only enable transitions if the user hasn't asked for reduced motion */
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}/* Only enable on viewports wide enough for the animation to feel good */
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
} Essa é uma verdadeira atualização. Você obtém o mesmo poder condicional que já possui com todos os outros recursos CSS. Consultas de mídia, <!-- THIS IS DEPRECATED - stop copying this from old tutorials --> , qualquer lógica de escopo que você desejar – tudo funciona porque o opt-in reside onde seus estilos residem.
<meta name="view-transition" content="same-origin">
Há também uma sutileza que importa: a regra CSS pode ser diferente na página antiga e na nova. Ambas as páginas precisam ativar a transição para disparo. Se a página A tiver /* THIS is the current opt-in - goes in your CSS */ mas a página B não, você não terá transição. Isso é realmente útil – significa que sua página 404 ou seu redirecionamento de login podem pular transições sem qualquer coordenação de JavaScript.
@view-transition {
navigation: auto;
}
Mais uma coisa digna de nota aqui: /* Only enable transitions if the user hasn't asked for reduced motion */ só entra em ação para navegações de mesma origem iniciadas pelo usuário. Se o usuário clicar em um link normal ou clicar no botão Voltar do navegador, você receberá uma transição. Mas
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}/* Only enable on viewports wide enough for the animation to feel good */ definido programaticamente, ou um link de origem cruzada, ou um envio de formulário com um
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
}@supports? Sem transição. O navegador é intencionalmente conservador sobre quando é acionado e, honestamente, essa é a decisão certa. Você não quer um cross-fade sofisticado em uma solicitação @supports que está criando um pagamento.
Olha, se você está seguindo um tutorial desatualizado e suas transições simplesmente não funcionam silenciosamente, é quase certo que é por isso. A meta tag fornecida no Chrome 111 , teve alguns meses de uso no mundo real e, em seguida, a equipe do Chrome a descontinuou em favor da regra CSS começando por volta do Chrome 126 . Nenhum aviso do console. Nenhum erro. A sintaxe antiga simplesmente não faz nada agora. Honestamente, um aviso de descontinuação no DevTools teria me poupado (e provavelmente a você) de muita dor, mas aqui estamos.
Troque a meta tag pela regra CSS. Esse é o primeiro passo. Todo o resto neste artigo se baseia nisso.
Sua transição morrerá aleatoriamente, e aqui está o porquê
// Drop this in your pages to see what's actually happening
window.addEventListener("pagereveal", (event) => {
if (!event.viewTransition) {
console.log(
"No view transition - page didn't opt in or browser skipped it",
);
return;
} // This is the one that'll save your sanity
event.viewTransition.finished
.then(() => console.log("Transition completed ✅"))
.catch((err) => {
// You'll see "TimeoutError" here and nowhere else
console.error("Transition killed:", err.name, err.message);
});
}); Aqui está o que ninguém coloca em sua postagem de blog: as transições de visualização entre documentos têm um tempo limite rígido de 4 segundos. Se a nova página não atingir um estado que o navegador considera “renderizável” dentro de 4 segundos após o início da navegação, a transição simplesmente… morre. Sem animação. Sem cross-fade. A nova página se encaixa como se as transições de visualização não existissem. E a menos que você tenha aquele ouvinte pagereveal conectado e seu console aberto, você não receberá nenhuma indicação de que algo deu errado.
Quatro segundos parece generoso, até que deixa de ser.
Pense no que acontece em um site real. Sua página carrega. O HTML chega, tudo bem, é rápido. Mas talvez você tenha uma grande imagem de herói que bloqueia a renderização. Talvez haja uma chamada de API lenta que seu servidor espera antes de enviar a resposta – uma página de produto acessando um serviço de inventário, um painel aguardando dados analíticos, qualquer coisa com renderização no lado do servidor que realmente funcione antes de responder. Talvez você esteja com uma conexão decente, mas a página tem três fontes da web sendo carregadas do Google Fonts com window.location.href = "/somewhere". Qualquer um deles pode fazer você ultrapassar a janela de 4 segundos, e o tempo limite não se importa por que você está lento. Isso apenas corta a transição.
A parte realmente enlouquecedora? Funciona perfeitamente no localhost. Seu servidor de desenvolvimento responde em 80 ms. A transição é manteiga. Você implanta na produção, a inicialização a frio de um lambda do servidor ou o cache CDN é perdido e, de repente, os usuários não obtêm nenhuma transição no primeiro clique. Você não pode reproduzi-lo localmente. Você começa a questionar tudo.
// You can also catch this on the OLD page using `pageswap`
// Useful for cleanup or logging which navigations fail
window.addEventListener("pageswap", (event) => {
if (event.viewTransition) {
event.viewTransition.finished.catch((err) => {
// Log it, send it to your analytics, whatever
console.warn("Outgoing transition aborted:", err.name);
});
}
});Então, o que você realmente faz a respeito?
Opção um: torne sua página mais rápida. Eu sei, um conselho inovador. Mas, falando sério – se a transição entre documentos estiver morrendo, isso é um sinal de que o carregamento da página está realmente lento. O tempo limite está agindo como um canário de desempenho. Olhe para a guia Desempenho no DevTools, execute uma auditoria do Lighthouse (que pode não ser perfeita ), descubra o que está bloqueando a primeira renderização. Este não é um conselho específico para a transição de visualização, mas o tempo limite obriga você a se preocupar com isso.
A opção dois é mais interessante , e é algo que eu gostaria de ter conhecido imediatamente.
<!-- Note: rel="expect" is newer and browser support is rolling out -->
<link rel="expect" href="#hero" blocking="render">Isto:
<link rel="expect" href="#hero" blocking="render">…diz ao navegador: “Não considere esta página renderizável até que um elemento correspondente a POST esteja no DOM.” Parece que isso tornaria as coisas mais lentas e, de certa forma, isso acontece – atrasa a primeira pintura. Mas para transições de visualização, isso é exatamente o que você quer: você está dizendo ao navegador para segurar o instantâneo até que o conteúdo importante esteja realmente lá, em vez de tirar uma captura de tela de uma página meio carregada ou, pior, o tempo limite expirar porque alguma imagem no rodapé ainda está baixando e bloqueando alguma coisa.
É uma troca. Você está escolhendo uma transição um pouco atrasada, mas suave, em vez de uma transição rápida, mas interrompida.
Honestamente, o limite de 4 segundos é provavelmente a decisão certa do ponto de vista do navegador. Você não quer que um usuário clique em um link e fique olhando para uma página congelada por 10 segundos enquanto o navegador espera para fazer uma animação sofisticada. Em algum momento, apenas mostrar a maldita página é melhor do que uma transição bonita. Mas eu gostaria que o Chrome mostrasse o tempo limite de forma mais visível – um aviso do DevTools, um marcador de desempenho, algo . No momento, ele falha silenciosamente e esse é o problema.
Mais uma coisa que vale a pena saber: o relógio de tempo limite começa quando a navegação começa, não quando o HTML da nova página começa a chegar. Contagens de latência da rede. As contagens vitais do núcleo da Web do tempo até o primeiro byte (TTFB). Se o seu servidor levar 2 segundos para responder e sua página levar 2,5 segundos para renderizar depois disso, você ultrapassou o limite, mesmo que nenhuma das metades pareça lenta por si só.
Uma dica de depuração que me salvou mais de uma vez: o DevTools do Chrome tem um painel Animações (está em “Mais ferramentas” caso você não o veja) que pode realmente capturar transições de visualização em ação. Você pode desacelerá-los para 10% da velocidade, reproduzi-los e inspecionar a árvore de pseudoelementos no meio da animação. Não é óbvio que funcione para transições de visualização, mas funciona. Entre isso e o ouvinte pagereveal acima, você pode diagnosticar a maioria dos problemas de tempo limite muito rapidamente.
Coloque esse ouvinte pagereveal no início. Observe seu console durante o teste. Você vai se agradecer mais tarde.
Por que suas imagens parecem caramelo
Este é mais fácil de mostrar primeiro com uma demonstração do mesmo documento (já que você pode executá-lo em um único arquivo), mas o problema e a correção são idênticos para transições entre documentos.
Execute isso. Clique na imagem. Observe o cachorro se transformar em uma massa boba.
A imagem em si tem pagereveal em ambos os lados. A miniatura parece boa, o herói parece bom. Mas durante a transição? O navegador não faz a transição do seu elemento font-display: block. Ele faz uma captura de tela do estado antigo, faz uma captura de tela do novo estado e se transforma entre eles. Essas capturas de tela são imagens raster planas. Seu cuidadosamente aplicado // You can also catch this on the OLD page using `pageswap` ? Perdido. O navegador está apenas dimensionando um bitmap de um tamanho de caixa para outro, e quando um quadrado de 150×150 é esticado em um retângulo de 600×300, você fica confuso.
// Useful for cleanup or logging which navigations fail
window.addEventListener("pageswap", (event) => {
if (event.viewTransition) {
event.viewTransition.finished.catch((err) => {
// Log it, send it to your analytics, whatever
console.warn("Outgoing transition aborted:", err.name);
});
}
});
Aqui está a solução:
/* THE FIX - target the transition pseudo-elements directly */
::view-transition-old(hero-img),
::view-transition-new(hero-img) {
/* Treat the snapshot like an image in a container - crop, don't stretch */
object-fit: cover;
overflow: hidden;
}Isso é tudo. Duas propriedades em dois pseudoelementos.
O que realmente está acontecendo: o navegador gera uma árvore de pseudoelementos para cada transição nomeada. Para um elemento com <!-- Note: rel="expect" is newer and browser support is rolling out -->, você obtém esta estrutura durante a animação:
<link rel="expect" href="#hero" blocking="render">
::view-transition
└── ::view-transition-group(hero-img)
├── ::view-transition-old(hero-img)
└── ::view-transition-new(hero-img) O <link rel="expect" href="#hero" blocking="render"> anima suavemente sua largura e altura das dimensões antigas para as novas. Esse é o retângulo em transformação que você vê. Dentro dele, os pseudoelementos #hero e pagereveal contêm os instantâneos de bitmap reais e, por padrão, eles são definidos como pagereveal – significa “esticar para preencher qualquer caixa em que você estiver, dane-se a proporção de aspecto”.
Mudar para pagereveal informa a esses instantâneos para manter sua proporção de aspecto e cortar o excesso. O mesmo modelo mental de uma imagem de fundo com <img>. A transição ainda anima a caixa de quadrado para retângulo (ou quaisquer que sejam suas formas), mas a imagem interna é cortada graciosamente em vez de distorcer.
Você também pode usar object-fit aqui se preferir ver a imagem completa com letterbox em vez de corte. Depende do que parece certo para o seu conteúdo. Mas /* THE FIX - target the transition pseudo-elements directly */ é o que você deseja 90% das vezes, especialmente para imagens de produtos e fotos de heróis.
::view-transition-old(hero-img),
::view-transition-new(hero-img) {
/* Treat the snapshot like an image in a container - crop, don't stretch */
object-fit: cover;
overflow: hidden;
}
Para transições entre documentos, o CSS é idêntico – basta colocá-lo nas folhas de estilo de ambas as páginas:
/* This works cross-document. Same selectors, same fix. */
/* Put it in your shared CSS file that both pages load. */
@view-transition {
navigation: auto;
}
::view-transition-old(hero-img),
::view-transition-new(hero-img) {
object-fit: cover;
}
/* You can also control the animation timing on the group */
::view-transition-group(hero-img) {
animation-duration: 0.4s;
animation-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
} Honestamente, acho que pagereveal deveria ser o padrão nesses pseudoelementos em vez de ::view-transition. Entendo por que a especificação escolheu
└── ::view-transition-group(hero-img)
├── ::view-transition-old(hero-img)
└── ::view-transition-new(hero-img)::view-transition – é previsível, corresponde ao padrão
└── ::view-transition-group(hero-img)
├── ::view-transition-old(hero-img)
└── ::view-transition-new(hero-img)// You can also catch this on the OLD page using `pageswap` em elementos substituídos em qualquer outro lugar no CSS – mas na prática, com que frequência você realmente deseja um bitmap esticado durante uma transição? Quase nunca. Você adicionará essa substituição basicamente em todas as transições de imagem que criar.
// Useful for cleanup or logging which navigations fail
window.addEventListener("pageswap", (event) => {
if (event.viewTransition) {
event.viewTransition.finished.catch((err) => {
// Log it, send it to your analytics, whatever
console.warn("Outgoing transition aborted:", err.name);
});
}
});
Mais uma variante que é útil quando as proporções são totalmente diferentes – digamos, uma miniatura alta de retrato fazendo a transição para um herói cinematográfico widescreen:
/* Fine-tune where the crop happens on each side of the transition */
::view-transition-group(hero-img) {
overflow: hidden;
border-radius: 8px; /* keep it pretty mid-flight */
}
::view-transition-old(hero-img) {
object-fit: cover;
object-position: center center;
}
::view-transition-new(hero-img) {
object-fit: cover;
object-position: center top; /* keep the top of the hero visible */
} Você pode definir diferentes valores new no antigo e no novo, o que permite controlar onde o corte acontece em cada lado da transição de forma independente. A miniatura antiga pode parecer melhor cortada do centro. O novo herói pode precisar ancorar-se no topo. Misture e combine.
Levei um tempo embaraçosamente longo para descobrir. A solução são duas linhas de CSS, mas se você não sabe que a árvore de pseudoelementos existe, você nem sabe o que direcionar. Agora você faz.
Os dois eventos que unem tudo
Você já viu pagereveal e pageswap aparecerem no código acima, mas vamos dar um passo atrás e falar sobre o que eles realmente são. Compreender esses dois eventos será importante, porque na Parte 2 nos apoiaremos fortemente neles para o padrão de nomenclatura just-in-time que faz com que as transições de visualização sejam realmente escalonadas.
As transições de visualização entre documentos acontecem em duas páginas que não têm conexão JavaScript entre si. A página A não conhece o DOM da página B. Como as páginas antigas e novas não têm como se comunicar diretamente, esses eventos são a única maneira de coordenar a transição de ambos os lados. A página B não existia quando a página A estava em execução. Então, como você coordena alguma coisa? Como você decide quais elementos nomear ou personaliza a transição com base no destino do usuário?
É para isso que servem esses dois eventos. Eles são seus ganchos para o ciclo de vida da transição, um em cada lado da navegação.
pageswap dispara na página de saída , logo antes de ser substituída. Esta é sua última chance de tocar no DOM da página antiga antes que o navegador faça um snapshot dela. O evento oferece duas propriedades principais:
-
object-fit: contain: o objeto ViewTransition para esta navegação, oucoverse nenhuma transição está acontecendo. -
/* This works cross-document. Same selectors, same fix. */: um objeto NavigationActivation que informa para onde o usuário está indo .
/* Put it in your shared CSS file that both pages load. */
@view-transition {
navigation: auto;
}::view-transition-old(hero-img),
::view-transition-new(hero-img) {
object-fit: cover;
}/* You can also control the animation timing on the group */
::view-transition-group(hero-img) {
animation-duration: 0.4s;
animation-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
}
Essa propriedade object-fit: cover é realmente útil. fill fornece o URL de destino e fill informa se é um object-fit, /* Fine-tune where the crop happens on each side of the transition */
::view-transition-group(hero-img) {
overflow: hidden;
border-radius: 8px; /* keep it pretty mid-flight */
}
::view-transition-old(hero-img) {
object-fit: cover;
object-position: center center;
}
::view-transition-new(hero-img) {
object-fit: cover;
object-position: center top; /* keep the top of the hero visible */
}, object-position (voltar/avançar) ou pagereveal. Isso significa que você pode personalizar o lado de saída da transição com base no destino. Em uma página de listagem de produtos, por exemplo, você pode verificar em qual produto o usuário clicou, encontrar o cartão correspondente e atribuir um view-transition-name apenas a esse elemento antes do instantâneo acontecer.
pagereveal dispara na página de entrada , logo após a página se tornar ativa, mas enquanto a transição ainda está em execução. Esta é sua chance de configurar o novo lado. O evento oferece:
-
object-fit: contain: mesmo negócio, o objeto ViewTransition oucover.
Na página de entrada, você verifica de onde o usuário veio de usando event.activation (por meio da API de navegação) e lê o URL atual de activation. Entre essas duas informações, você sabe exatamente que tipo de navegação aconteceu e pode configurar os elementos de transição da página recebida de acordo.
Aqui está o ciclo de vida completo em ordem:
- O usuário clica em um link na página A.
-
pageswapé acionado na página A. Esta é a sua janela para nomear elementos e personalizar o estado de saída. - O navegador captura a página antiga (capturando quaisquer elementos nomeados).
- A navegação acontece, uma nova página é carregada.
-
pagerevealdispara na página B. Você pode nomear elementos e personalizar o estado de entrada. - O navegador captura a nova página.
- A transição é animada entre os dois instantâneos.
-
pushresolve (ou rejeita) em ambos os lados.
Três coisas para ter em mente com esses eventos:
Primeiro, sempre proteja com replace no topo de seus manipuladores. pagereveal na verdade é acionado em a cada navegação – carregamento inicial da página, voltar/avançar, os trabalhos – não apenas visualizar transições. Se não houver nenhuma transição acontecendo, object-fit: contain será cover, e seu manipulador deverá sair normalmente. Esses manipuladores são açúcar de transição, não lógica de aplicativo. Nunca coloque neles efeitos colaterais que você precisa para que a página funcione.
Segundo, pageswap só é acionado se a página antiga tiver optado por visualizar transições e a navegação for da mesma origem. Se o usuário clicar com o botão do meio para abrir em uma nova guia ou se a navegação for de origem cruzada, o evento não será acionado ou object-fit: contain será cover. Tudo bem, sua cláusula de guarda cuida disso.
Terceiro, e isso é fácil de ignorar: ambos os eventos dão acesso a push, que é uma promessa que é resolvida quando a transição é concluída ou rejeitada se algo der errado (como um tempo limite). Sempre use isso para limpeza, como na remoção de view-transition-name valores que você definiu dinamicamente, redefinindo o estado, qualquer que seja. Nomes obsoletos de uma transição anterior arruinarão a próxima.
Temos usado esses eventos levemente até agora – um ouvinte pagereveal para capturar tempos limite, um ouvinte pageswap para registro. Na Parte 2 desta pequena série, eles se tornam a espinha dorsal de toda a estratégia de expansão. Fique atento.
O que vem a seguir
Isso cobre as três dicas que vão te incomodar primeiro: a meta tag obsoleta que silenciosamente não faz nada, o tempo limite de 4 segundos que mata as transições sem avisar você e a distorção da imagem que transforma cada mudança de proporção de aspecto em um espelho de diversão. Além dos dois eventos que fornecem acesso a todo o ciclo de vida.
Na Parte 2, abordaremos o problema de dimensionamento. Quando você tem uma grade de 48 cartões de produtos e cada um precisa de um view-transition-name exclusivo, como evitar que seu CSS exploda? A resposta envolve view-transition-class (que é diferente de view-transition-name de maneiras que não são óbvias), um padrão de nomenclatura just-in-time usando o pageswap e pagereveal eventos que acabamos de cobrir. E uma observação crítica: abordaremos prefers-reduced-motion na Parte 2, mas se você não tirar mais nada desta série, veja isto: as animações podem literalmente deixar as pessoas fisicamente enjoadas. Verifique sempre essa preferência e respeite-a.
As pegadinhas ficaram para trás. Agora é hora de escalar.
Série de transições de visualização entre documentos
- As pegadinhas que ninguém menciona (Você está aqui!)
- Dimensionando transições de visualização em centenas de elementos (Próxima segunda-feira!)
Transições de visualização entre documentos: as pegadinhas que ninguém menciona originalmente escrito à mão e publicado com amor em CSS-Tricks . Você realmente deveria receber o boletim informativo também.
