CSS View Transitions : des transitions de page fluides sans une ligne de JavaScript

Le 7 juillet 2026, le designer d'interface et développeur full-stack britannique Max Glenister a détaillé sur son blog comment il anime désormais la navigation entre ses pages avec une seule déclaration CSS, sans routeur, sans appel fetch et sans bidouiller l'historique du navigateur. Son cas concret vaut le détour : il documente précisément ce qui marche, ce qui casse au premier essai, et comment le corriger.

Ce qu'il décrit s'appelle les cross-document view transitions, la version purement CSS des transitions de page. Elle mérite l'attention de tout développeur ou toute agence qui veut donner à un site classique, multi-pages, une sensation d'application fluide, sans ajouter la moindre ligne de JavaScript ni basculer vers une single-page app.

Un peu de contexte, pour ceux qui découvrent le sujet

Pendant des années, animer un changement de page a voulu dire réinventer la navigation en JavaScript : jQuery hier, pjax ensuite, puis les routeurs des single-page apps aujourd'hui. Le principe reste identique à chaque fois : intercepter le clic sur le lien, aller chercher le contenu, l'injecter dans la page, et animer la bascule soi-même. Ça fonctionne, mais ça oblige chaque navigation, même sur un simple blog statique, à transiter par un routeur JavaScript qui n'aurait sinon aucune raison d'exister.

Les cross-document view transitions suppriment cette couche. Le navigateur effectue une vraie navigation vers une vraie URL : il capture simplement la page sortante au moment où elle quitte l'écran, capture la page entrante au moment où elle arrive, et laisse CSS animer le passage de l'une à l'autre. Il existe aussi une API JavaScript, document.startViewTransition(), pour animer des changements à l'intérieur d'une seule page dans une SPA. C'est un outil différent pour un besoin différent : ici, il n'est question que de la version CSS, celle qui s'applique à un site multi-pages classique, sans aucun framework de routage.

Activer la fonctionnalité : une seule règle CSS

Tout se déclenche avec un bloc @view-transition et sa propriété navigation: auto, à envelopper dans une media query prefers-reduced-motion pour respecter les utilisateurs qui ont demandé moins d'animations sur leur système :

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Résultat immédiat : chaque navigation vers une page du même site se fait en fondu enchaîné plutôt qu'en coupure brute. Chrome, Edge et Safari prennent en charge cette règle depuis mi-2024. Firefox, de son côté, ignore simplement le bloc et navigue normalement. Il n'y a donc rien à détecter ni à isoler derrière un @supports, le pire cas possible reste une page qui change sans animation, exactement comme avant l'existence de la fonctionnalité.

Aller au-delà du simple fondu

Le fondu par défaut s'applique à la page entière, comme un seul bloc. C'est propre, mais limité. Pour obtenir des animations différenciées, comme une colonne qui glisse pendant qu'une autre reste fixe, il faut nommer les éléments individuellement avec view-transition-name, puis leur appliquer des animations CSS classiques sur les pseudo-éléments ::view-transition-old() et ::view-transition-new() que le navigateur génère automatiquement pour chaque élément nommé :

.sidebar-left { view-transition-name: first-column; }
.page-content { view-transition-name: middle-column; }

@keyframes slide-left-out {
  to { transform: translateX(-50vw) scaleX(0); opacity: 0; }
}
@keyframes slide-left-in {
  from { transform: translateX(-50vw) scaleX(0); opacity: 0; }
}

::view-transition-old(middle-column) {
  animation: slide-left-out 0.1s forwards;
}
::view-transition-new(middle-column) {
  animation: slide-left-in 0.2s forwards;
  mix-blend-mode: normal;
}

Dans le cas décrit par Max Glenister, la sortie est deux fois plus rapide que l'entrée (0,1s contre 0,2s), ce qui donne l'impression que l'ancienne page s'efface pour laisser la place plutôt qu'un échange symétrique. Le mix-blend-mode: normal compte aussi : le mode de fusion par défaut du navigateur délave le contenu en plein mouvement, et le repasser en normal règle le problème. Il ajoute enfin un z-index explicite sur chaque ::view-transition-group(), sans quoi la colonne qui glisse passe au-dessus de la sidebar au lieu de filer en dessous. Les widgets de sa sidebar (tags, mentions, articles liés) reçoivent chacun leur propre nom de transition et un simple fondu, pour changer de contenu sur leur propre rythme sans faire bouger le reste de la mise en page.

Le piège du flash de contenu mal aligné

Le navigateur capture la taille et la position de chaque élément nommé avant et après la navigation. Si cette boîte n'est pas stable, l'animation démarre au mauvais endroit pendant une fraction de seconde, un flash visible avant que tout se recale. Max Glenister a identifié deux causes concrètes sur son propre site.

La première : une photo d'auteur avec max-width et aspect-ratio définis, mais sans largeur ferme. Sans base de calcul, aspect-ratio ne pouvait pas déduire de hauteur, et la boîte s'effondrait avant le chargement de l'image. Ajouter une largeur explicite (width: 25rem) a réglé le problème, même si max-width: 100% la plafonne ensuite dans la plupart des mises en page.

La seconde : sa colonne centrale utilisait une piste de grille en 5fr pure, un ratio sans plancher. Elle se redimensionnait donc légèrement selon le contenu des colonnes voisines d'une page à l'autre, et la transition capturait deux largeurs différentes de quelques pixels : un saut visible plutôt qu'un glissement propre. Donner un plancher avec minmax(50%, 5fr) a réglé ce second cas. Il signale aussi un piège plus discret : les cross-document view transitions ont un délai d'expiration silencieux de quatre secondes. Si la nouvelle page n'a pas fini de s'afficher dans ce délai, la transition échoue sans erreur ni message dans la console, juste une navigation qui redevient brutale sur une connexion lente.

Comment l'essayer sur votre propre site

Aucune bibliothèque, aucun build step particulier n'est nécessaire. Trois lignes de CSS suffisent pour un premier test sur n'importe quel site multi-pages : ajoutez le bloc @view-transition vu plus haut dans votre feuille de style globale, vérifiez le rendu dans un navigateur Chromium ou Safari récent, puis nommez progressivement les éléments que vous voulez voir animer séparément. La dégradation ne demande aucun effort : les navigateurs qui ne supportent pas la règle l'ignorent et affichent une navigation normale, sans accroc ni erreur de style.

Notre lecture chez CZSyn

Ce que nous apprécions dans les cross-document view transitions, c'est qu'elles sont additives : elles s'ajoutent à une navigation qui fonctionnait déjà, au lieu de la remplacer par un routeur applicatif. Pour un site vitrine, un blog ou une boutique e-commerce français qui veut une sensation « app » sans en payer le coût technique, c'est un excellent rapport effort/résultat. Pas de couche JavaScript supplémentaire à maintenir, pas de perte de la navigation native du navigateur, et de vraies URLs à chaque page, ce qui reste précieux pour le référencement et l'analytics.

Le point de vigilance, à nos yeux, tient aux deux pièges décrits ci-dessus : ils sont faciles à manquer en développement sur une connexion rapide et n'apparaissent qu'en production, sur des pages avec un contenu variable. Nous recommandons de tester systématiquement la transition avec des contenus de longueurs différentes (texte court, texte long, image manquante) avant de la livrer, et de garder un œil sur le délai de quatre secondes si vos pages chargent des ressources lourdes. Le tout reste compatible avec un générateur de site statique comme Astro, puisqu'il ne s'agit que de CSS posé sur une navigation qui existe déjà.

Sources primaires

• Max Glenister, « How I'm using CSS View Transitions on this blog », 7 juillet 2026.
• MDN Web Docs, « View Transitions API », documentation officielle.