L'API View Transition change la donne pour le développement Web. Que votre site Web comporte une seule ou plusieurs pages, cette API performante vous permet de créer des transitions fluides entre les vues, pour des expériences de type natif qui captivent les utilisateurs. Actuellement disponible dans Chrome, et les mêmes transitions d'affichage des documents seront bientôt disponibles dans Safari.
Alors que de plus en plus de personnes s'intéressent à l'API View Transition, il est temps de réfuter certaines idées reçues.
Idée fausse 1: l'API View Transition prend des captures d'écran
Lors de l'exécution d'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. Considérez-le 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, des démonstrations comme celle-ci fonctionnent: la vidéo, qui provient du nouvel instantané, continue à être lue pendant la transition de vue.
La logique et le CSS utilisés pour cela 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 s'achève lorsqu'une nouvelle transition commence.
Idée fausse 3: il n'est pas possible d'implémenter des transitions d'affichage en raison de la compatibilité des navigateurs
De nombreux développeurs craignent de ne pas pouvoir implémenter les transitions de vue, car elles ne sont compatibles qu'avec Chrome. La bonne nouvelle, c'est que Safari travaille sur cette fonctionnalité et l'intégrera dans la prochaine version de Safari 18.
Toutefois, ne laissez pas une prise en charge instable des navigateurs vous empêcher d'implémenter des transitions d'affichage. Les transitions entre les vues sont idéales pour les améliorations progressives. La documentation d'origine indique une méthode permettant d'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 pour afficher le même document, vous disposez de la version enrichie et animée. Si ce n'est pas le cas de votre navigateur, vous bénéficiez de l'expérience actuelle. Au fil du temps, étant donné que de plus en plus de navigateurs sont compatibles avec les transitions d'affichage, de plus en plus d'utilisateurs profiteront automatiquement de cette version enrichie.
Il en va de même pour les transitions entre documents. Les navigateurs non compatibles ignoreront l'activation CSS lors de l'analyse des feuilles de style.
Cette approche a été appliquée avec succès dans le secteur de l'e-commerce, comme détaillé dans cette étude de cas.
Idée fausse 4: les transitions de vue rompent l'affichage incrémentiel
Il existe des affirmations selon lesquelles des transitions de vue rompent l'affichage incrémentiel. C'est faux: des transitions d'affichage entre documents ont été spécifiées afin de ne pas rompre cet aspect fondamental du Web.
Les navigateurs commencent à afficher une page lorsque son contenu est "suffisant". Dans la plupart des navigateurs, cela se produit après le chargement de toutes les feuilles de style dans le fichier <head>, l'analyse de tous les codes JavaScript qui bloquent l'affichage dans le fichier <head> et le chargement d'un balisage suffisant. Les transitions d'affichage entre documents n'apportent aucune modification: le contenu requis pour First Contentful Paint n'a pas été modifié. Après ce premier rendu, le navigateur peut afficher (et effectuera progressivement) le contenu nouvellement reçu.
Vous pouvez choisir de bloquer l'affichage 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 l'heuristique du navigateur utilisée pour décider quand effectuer son 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 intègre des mesures de protection. Par exemple, lorsque la balise de fermeture </html> est visible, mais que l'élément bloquant ne l'était pas, l'affichage n'est plus bloqué. Vous pouvez également 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 de l'affichage doit être évalué au cas par cas. Par défaut, évitez d'utiliser blocking=render, sauf si vous pouvez mesurer et évaluer activement son impact sur vos utilisateurs en mesurant l'impact sur vos métriques de performances.
Idée fausse 5: le processus de création d'instantanés 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. C'est pourquoi l'utilisateur voit l'ancienne page un peu plus longtemps qu'avec les transitions 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. Aucune étape supplémentaire de mise en page ou de repeinture n'est donc nécessaire 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 emploie souvent l'API View Transitions. Cela est incorrect. Cette API est appelée "API View Transition". Notez la transition au singulier.
Cette idée fausse vient de certains articles (y compris, à un moment donné, nos propres documents sur 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.