A API View Transition permite atualizar o DOM em uma única etapa, gerando uma transição animada entre os dois estados.
Esse tipo de transição era um recurso frequentemente solicitado pelos desenvolvedores, inclusive por mim, e acho que conseguimos implementá-lo de uma forma que equilibra bons padrões com extensibilidade e personalização. Parece que estamos nos gabando, mas o feedback dos desenvolvedores foi fundamental para o design desse recurso. Um protótipo anterior desse recurso era muito menos flexível, e as pessoas (como você?) que tiveram tempo para brincar com os protótipos e dar feedback fizeram com que repensássemos tudo. Valeu!
Para entender melhor o recurso e conferir algumas demonstrações, consulte nosso guia. Se você achar que algo não foi abordado, entre em contato comigo no Twitter, no Mastodon ou por e-mail.
No momento, a API View Transitions só está disponível no Chrome, mas ela pode ser usada como um aprimoramento progressivo. O guia inclui uma função auxiliar que pode ser usada em todos os navegadores, mas apenas os que oferecem suporte a transições de visualização vão receber a animação.
Desenvolvemos esse recurso no Grupo de Trabalho do CSS, com a contribuição de outros fornecedores de navegadores e independentes. Não sabemos se ou quando outros navegadores vão adotar as transições de visualização, mas fique de olho na posição da Mozilla em relação aos padrões e na posição do WebKit em relação aos padrões.
Mas ainda não terminamos.
A página de destino da funcionalidade no Chrome 111 é apenas a primeira versão. Esperamos que já tenhamos encontrado todos os bugs, mas registre qualquer problema que encontrar em crbug.com, de preferência com uma demonstração reduzida. Se você não sabe como fazer isso ou não se sente confortável, entre em contato comigo no Twitter, no Mastodon ou por e-mail. Vou ajudar você.
Esta versão é uma parte pequena, mas útil, de uma imagem maior. Já fizemos alguns ajustes nesse recurso para garantir que as peças que estamos enviando hoje sejam compatíveis com o futuro.
Confira uma prévia do que estamos pensando. Elas não estão em ordem de prioridade (talvez a primeira seja a mais importante para muitas pessoas). Por isso, gostaríamos de receber seu feedback sobre quais adições são mais importantes para você.
Transições entre documentos
Acho que é nisso que a maioria dos desenvolvedores quer que trabalhemos em seguida, e a boa notícia é que já estamos trabalhando nisso.
A API View Transitions foi projetada para funcionar em documentos de mesma origem. A única diferença é que, em vez de startViewTransition sinalizar a mudança de estado do DOM, a navegação em si vai sinalizar essa mudança.
Nosso protótipo está atrás da flag chrome://flags/#view-transition-on-navigation. Confira uma demonstração super simples e uma mais complexa.
Para avançar, precisamos descobrir como cada página ativa a transição. No momento, estamos usando uma metatag: <meta name="view-transition" content="same-origin">, mas achamos que o CSS é um lugar melhor para isso. Também queremos facilitar a identificação do tipo de página de origem da transição, de preferência sem precisar escrever JavaScript.
Há muito trabalho a ser feito, e preferimos fazer isso "certo" do que "rápido", mas é definitivamente uma prioridade para nós.
Animações geradas pelo compositor
Escolhemos animar a largura e a altura em grupos de transição por padrão porque é muito mais fácil personalizar. No entanto, isso significa que a animação é executada na linha de execução principal, o que não é ideal, principalmente durante o carregamento da página.
Planejamos detectar as animações padrão e as personalizações comuns e, em seguida, reinterpretá-las como animações geradas pelo compositor para melhorar a performance.
Transições com escopo
No momento, as transições de SPA são aplicadas a todo o documento, e apenas uma transição pode ser executada por vez. Queremos apresentar um recurso que permita que as transições sejam aplicadas a um elemento específico para que vários componentes de página possam executar transições de forma independente.
Isso permitiria, por exemplo, que um player de vídeo incorporado usasse transições de visualização ao mesmo tempo que um widget de chat incorporado.
Grupos de transição aninhados
No momento, todos os ::view-transition-groups são irmãos. Isso geralmente é bom, porque permite que as visualizações façam a transição de um contêiner para outro, e você não precisa se preocupar com o corte.
No entanto, às vezes você quer que uma visualização seja cortada por algum pai, que também pode estar envolvido na transição.
Queremos investigar uma opção de ativação que coloque uma ::view-transition-group específica dentro de outra ::view-transition-group.
Classes de transições
Cada view-transition-name precisa ser único. É assim que identificamos que um elemento específico é conceitualmente "o mesmo" em ambos os lados da mudança do DOM, mesmo que não seja literalmente o mesmo elemento.
No entanto, às vezes, elementos com view-transition-names diferentes precisam usar o mesmo tipo de animação. No momento, isso significa adicionar uma regra de seletor para cada view-transition-name.
Gostaríamos de adicionar uma maneira de criar classes de transições para superar essa limitação.
Ignorar elementos fora da tela
Se você atribuir um view-transition-name a um elemento, ele vai participar da transição como um grupo próprio. Às vezes, isso não é ideal. Por exemplo, se você atribuir um view-transition-name a um cabeçalho e passar de um estado em que rolou para baixo 2.000 pixels para um estado na parte de cima da página, o cabeçalho vai ser animado a 2.000 pixels de distância, o que parece errado em termos de tempo.
Em vez disso, queremos adicionar uma opção em que um elemento será ignorado, como se ele não tivesse um view-transition-name, se ele estiver totalmente fora da viewport.
Já é possível fazer isso com JavaScript definindo style.viewTransitionName dinamicamente, mas parece que precisamos de uma solução declarativa para isso.
Animações orientadas por requestAnimationFrame
Já é possível criar animações de transição de visualização com JavaScript usando a API Web Animations, mas às vezes é necessário controlar as coisas quadro a quadro com requestAnimationFrame.
Isso já é possível, mas é um pouco complicado. Confira uma demonstração com alguns assistentes que podem ser úteis. Queremos que ele não seja hackeado.
Vamos fazer isso em duas partes. Primeiro, fornecendo uma API para indicar quando a animação é concluída. E, em segundo lugar, oferecendo acesso JavaScript a pseudoelementos. Essa segunda parte pode ser um trabalho muito grande, mas parece ser a coisa certa a se fazer a longo prazo.
Agora, crie transições de visualização incríveis!
Espero que você também esteja animado com o presente e o futuro desse recurso. Se você tiver algum feedback ou quiser mostrar algumas transições de visualização que criou, sejam elas suaves e funcionais ou apenas simples bobas, entre em contato comigo no Twitter ou no Mastodon.