Idées reçues sur les transitions de vue

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 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.

Vidéo en cours de lecture participant à une transition de vue Démonstration minimale. Source.

La logique et le CSS utilisés à cette fin sont détaillés dans notre documentation.

Idée reçue 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 anciens et nouveaux états. 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 cet arbre 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 de vue par document à la fois. 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, à mesure que de plus en plus de navigateurs seront compatibles avec les transitions de vue, un plus grand nombre d'utilisateurs pourront profiter de cette version enrichie, automatiquement.

Il en va de même pour les transitions de vue entre les documents. Les navigateurs qui ne les acceptent pas ignoreront l'activation du CSS lors de l'analyse des feuilles de style.

Cette approche a été mise en œuvre avec succès dans l'e-commerce, comme l'explique 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 utile lorsque vous souhaitez vous assurer que les éléments participant à la transition de vue 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é. 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 du rendu doit être utilisé avec précaution. 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 son impact 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'ancienne vue reste visible pour l'utilisateur. Par conséquent, l'utilisateur voit l'ancienne page un peu plus longtemps que sans transition de vue. Ce délai est cependant négligeable, en réalité seulement quelques images. Dans Chrome, l'impact de pageswap, par exemple, est de deux frames obsolètes au maximum: un pour exécuter la logique et un frame supplémentaire pour s'assurer que les instantanés ont été composés et mis en cache.

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 reçue supplémentaire: c'est l'API View Transitions

Lorsqu'on parle de transitions 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 vous souvenir du nom correct, vous devez utiliser l'API View Transition (une seule) pour créer une ou plusieurs transitions de vue.