L'API View Transition est un outil révolutionnaire pour le développement Web. Que votre site Web soit à une ou plusieurs pages, cette API puissante vous permet de créer des transitions fluides entre les vues, ce qui offre une expérience semblable à celle d'une application native qui captive les utilisateurs. Actuellement disponible dans Chrome, les mêmes transitions de vue de document seront bientôt disponibles dans Safari.
De plus en plus de personnes commencent à s'intéresser à l'API View Transition. Il est temps de dissiper certaines idées reçues.
Idée reçue n° 1: L'API View Transition prend des captures d'écran
Lorsque vous exécutez une transition de vue, l'API prend des instantanés de l'ancien et du nouvel état du contenu. Ces instantanés sont ensuite animés, comme indiqué dans la section Fonctionnement de ces transitions de la documentation.
Bien que vous puissiez utiliser le terme "capture d'écran" pour désigner l'ancien instantané, le nouvel instantané n'est pas une capture d'écran, mais une représentation en direct du nœud. Vous pouvez le considérer comme un élément remplacé.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Grâce à cet aspect en direct, les démonstrations comme celle-ci fonctionnent: la vidéo, issue du nouvel instantané, continue de se lire pendant la transition de vue.
La logique et le CSS utilisés à cette fin sont détaillés dans notre documentation.
Idée fausse 2: la capture de plusieurs éléments entraîne l'exécution de plusieurs transitions de vue.
Lorsque vous capturez plusieurs éléments, le processus de création d'instantanés capture tous les états, anciens et nouveaux. Lorsque vous capturez un .box en plus de l'élément :root, vous obtenez cette pseudo-arborescence:
::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)
Bien que cette arborescence contienne plusieurs paires d'instantanés, une seule transition de vue est exécutée.
Actuellement, Chrome ne peut exécuter qu'une seule transition d'affichage par document en même temps. Essayez de cliquer rapidement dans cette démonstration pour lancer une nouvelle transition de vue. Vous remarquerez que la transition en cours saute jusqu'à la fin lorsqu'une nouvelle commence.
Idée reçue 3: Vous ne pouvez pas implémenter de transitions d'affichage en raison de la compatibilité du navigateur
De nombreux développeurs craignent de ne pas pouvoir implémenter de transitions de vue, car elles ne sont compatibles qu'avec Chrome. Bonne nouvelle : Safari travaille sur ce problème et l'inclura dans la future version Safari 18.
Toutefois, ne laissez pas la compatibilité inégale des navigateurs vous empêcher d'implémenter des transitions de vue dès aujourd'hui. Les transitions de vue sont le matériau idéal pour l'amélioration progressive. La documentation d'origine explique comment ajouter cette méthodologie à votre code.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Si votre navigateur est compatible avec les transitions d'affichage du même document, vous obtenez la version enrichie et animée. Si ce n'est pas le cas, vous bénéficiez de l'expérience actuelle. Au fil du temps, étant donné que de plus en plus de navigateurs prennent en charge les transitions de vue, de plus en plus d'utilisateurs profiteront de cette version enrichie, le tout automatiquement.
Il en va de même pour les transitions de vue entre les documents. Les navigateurs non compatibles ignoreront l'activation CSS lors de l'analyse des feuilles de style.
Cette approche a été mise en œuvre avec succès dans l'e-commerce, comme détaillé dans cette étude de cas.
Idée reçue 4: Les transitions d'affichage interrompent le rendu incrémentiel
Il est affirmé que les transitions de vue interrompent le rendu incrémentiel. Ce n'est pas vrai: les transitions entre les vues de documents ont été spécifiées pour ne pas interrompre cet aspect fondamental du Web.
Les navigateurs commencent à afficher une page lorsqu'ils disposent de suffisamment de contenu. Dans la plupart des navigateurs, cela se produit après le chargement de toutes les feuilles de style dans <head>, l'analyse de tout le code JavaScript bloquant le rendu dans <head> et le chargement d'une balise suffisante. Les transitions de vue entre les documents ne changent rien à cela: le contenu requis pour First Contentful Paint n'est pas modifié. Après ce premier rendu, le navigateur peut et va progressivement afficher le contenu nouvellement reçu.
Vous pouvez choisir de bloquer le rendu jusqu'à ce qu'un élément spécifique soit présent dans le DOM. Cela est pratique lorsque vous souhaitez vous assurer que les éléments participant à la transition d'affichage sont présents sur la nouvelle page.
Pour ce faire, utilisez cette balise de lien:
<link rel="expect" blocking="render" href="#elementId">
Cela remplace les heuristiques du navigateur utilisées pour décider du moment où effectuer le premier rendu: le premier rendu est retardé jusqu'à ce que l'élément spécifié soit présent dans l'arborescence DOM.
Ce blocage manuel est doté de certaines mesures de sécurité intégrées. Par exemple, lorsque la balise </html> de fermeture est détectée, mais que l'élément bloquant ne l'a pas été, le rendu n'est plus bloqué. En outre, vous pouvez ajouter votre propre logique de délai avant expiration, qui supprime l'attribut bloquant à tout moment.
Il est évident que le blocage de l'affichage doit être utilisé avec prudence. L'impact du blocage du rendu doit être évalué au cas par cas. Par défaut, évitez d'utiliser blocking=render, sauf si vous pouvez mesurer et évaluer activement l'impact qu'il a sur vos utilisateurs, en mesurant l'impact sur vos métriques de performances.
Idée reçue 5: Le processus de création de snapshots est lent ou coûteux
Pendant que l'API View Transition prépare la nouvelle vue et obtient ses instantanés, l'utilisateur peut toujours voir l'ancienne. Par conséquent, l'utilisateur voit l'ancienne page un peu plus longtemps que sans transition de vue. Ce délai est toutefois négligeable : en réalité, il ne contient que quelques images. Dans Chrome, par exemple, l'impact de pageswap est de deux images obsolètes au maximum: une pour exécuter la logique, et une autre pour garantir la composition et la mise en cache des instantanés.
De plus, les données des instantanés sont extraites directement du compositeur. Il n'est donc pas nécessaire d'effectuer d'étapes de mise en page ou de repeinture supplémentaires pour obtenir les données d'instantané.
Idée fausse bonus: il s'agit de l'API View Transitions
Lorsqu'on parle de transition de vue, on fait souvent référence à l'API View Transitions. Cela est incorrect. L'API s'appelle "API View Transition" (API de transition d'affichage). Notez le singulier "transition".
Cette idée fausse provient de certains articles, y compris de nos propres documentations sur le DCC, qui utilisent le mauvais terme.
Pour retenir le nom correct, utilisez l'API View Transition pour créer une ou plusieurs transitions de vue.