View Transitions API : le confort d'une SPA, sans jamais en coder une

Pendant quinze ans, l'argument massue des SPA a été le confort, pas la technique : « les transitions entre pages sont fluides, pas de flash blanc ». Pour ce confort, on a accepté des routeurs côté client, des bundles obèses et la gestion manuelle de tout ce que le navigateur faisait gratuitement. La View Transitions API vient de rendre cet échange absurde : les transitions fluides entre vraies pages HTML, c'est désormais du CSS.

La version multi-pages : deux lignes, pas une de plus

Le mode cross-document s'active par une règle CSS des deux côtés de la navigation :

@view-transition {
  navigation: auto;
}

Chaque navigation entre deux pages du même site cesse de « flasher » : le navigateur capture l'ancienne vue, charge la nouvelle, et fond l'une dans l'autre. Zéro JavaScript, zéro routeur, zéro hydratation. Ton site PHP multi-pages de la vieille école vient d'acquérir la fluidité qu'on te vendait contre un framework. Quinze ans d'architecture justifiée par un fondu enchaîné : il fallait oser.

Comment ça marche dessous

Au moment de la transition, le navigateur crée des instantanés : l'ancienne page devient une image figée, la nouvelle arrive dessous, et des pseudo-éléments (::view-transition-old, ::view-transition-new) s'animent en CSS standard. Par défaut : un cross-fade sobre. Mais tout est personnalisable :

::view-transition-old(root) {
  animation: 200ms ease-out both slide-out;
}
::view-transition-new(root) {
  animation: 250ms ease-out both slide-in;
}
@keyframes slide-out { to { transform: translateX(-30px); opacity: 0; } }
@keyframes slide-in  { from { transform: translateX(30px); opacity: 0; } }

Ce sont des animations CSS ordinaires : durées, easings, keyframes que tu connais déjà. Garde la main légère : 200-300 ms, pas plus. La transition doit dire « on a bougé », pas « installe-toi, ça va durer ».

Le tour de magie : les éléments partagés

Le vrai spectacle, c'est view-transition-name. Donne le même nom à un élément présent sur les deux pages, et le navigateur le morphe de l'une à l'autre :

.card-vignette   { view-transition-name: article-hero; }
/* page article : */
.article-image   { view-transition-name: article-hero; }

Résultat : la vignette cliquée dans la liste glisse et s'agrandit pour devenir l'image d'en-tête de l'article. L'effet « app native » par excellence (celui que les SPA obtenaient à coups de bibliothèques d'animation et de calculs de FLIP) en deux déclarations CSS. Contrainte à connaître : chaque nom doit être unique par page (sur une liste, injecte un nom par item, article-42, côté serveur ; ton template s'en charge en une ligne).

Progressive enhancement par construction

Le meilleur design de cette API est philosophique plus que technique : un navigateur qui ne la connaît pas... navigue normalement. Pas de polyfill, pas de détection, pas de plan B à coder : le plan B est le comportement d'origine du web. Le support progresse bien (voir l'état sur Can I use) et pendant ce temps, rien ne casse pour les autres. C'est l'amélioration progressive dans sa forme la plus pure : le confort pour ceux qui peuvent, le fonctionnel pour tous.

Seul réglage d'hygiène : respecter prefers-reduced-motion en désactivant les animations personnalisées pour ceux qui l'ont demandé. Quatre lignes de media query, on ne négocie pas.

Avec HTMX, le combo naturel

Pour les navigations partielles, la version same-document de l'API (document.startViewTransition()) anime les remplacements de fragments, et HTMX l'intègre nativement : hx-swap="innerHTML transition:true" suffit. La boucle est bouclée : serveur qui rend du HTML, fragments qui glissent, pages qui s'enchaînent en douceur. L'expérience complète d'une SPA moderne, avec l'architecture d'un site de 2005 et le budget maintenance qui va avec.

Il faut mesurer ce qui vient de se passer : le dernier avantage perceptible des SPA sur les sites multi-pages vient d'être absorbé par la plateforme. C'est le cycle éternel du web : les frameworks défrichent, le standard récupère, et ceux qui avaient parié sur la plateforme touchent les intérêts. Les paris ennuyeux ont encore gagné ; ils ont l'habitude, remarque.

FAQ

Faut-il du JavaScript pour les View Transitions multi-pages ?

Non : la règle CSS @view-transition { navigation: auto } sur les deux pages suffit. Le JS n'intervient que pour les transitions same-document.

Que se passe-t-il sur un navigateur non compatible ?

Rien de cassé : la navigation reste classique. L'API est du progressive enhancement par construction, sans polyfill.

Comment faire le morphing d'une vignette vers une image d'article ?

Donner le même view-transition-name à l'élément sur les deux pages ; le navigateur anime la position et la taille automatiquement.