Enchaîner deux pages sans les faire clignoter

Pendant dix ans, la même phrase a servi à vendre des architectures lourdes : « un site classique clignote quand on change de page, une application web, non ». C’était vrai. Chaque navigation démontait tout et remontait tout, et l’œil voyait le blanc entre les deux. Pour l’éviter, on remplaçait la navigation du navigateur par du JavaScript qui interceptait les clics, allait chercher le contenu et remplaçait un morceau de la page. Des centaines de kilo-octets, un historique à réimplémenter, un bouton « précédent » qui finit toujours par se tromper quelque part.

Le navigateur sait maintenant le faire tout seul.

@view-transition {
  navigation: auto;
}

Deux lignes dans la feuille de style, sur les deux pages, même origine. Le navigateur prend une image de l’ancienne page, une de la nouvelle, et fond l’une dans l’autre. Le flash disparaît, la navigation reste celle du navigateur, et pas un octet de JavaScript n’est ajouté.

Aller plus loin que le fondu

Le fondu par défaut suffit dans la plupart des cas. Quand un élément est présent des deux côtés, on peut le nommer, et le navigateur le déplace au lieu de le fondre.

.logo { view-transition-name: logo; }

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 220ms;
}

Un nom, un seul, par page : deux éléments portant le même nom sur la même page annulent la transition. Le cas typique est une liste où l’on nomme la vignette de chaque article ; il faut alors ne nommer que celle sur laquelle on a cliqué, ce qui, sur un site statique, se règle en posant le nom depuis l’attribut de l’élément plutôt que sur une classe partagée.

Une chose que le navigateur ne fait pas à votre place, et qui est la faute la plus fréquente : couper l’effet pour ceux qui l’ont demandé.

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none;
  }
}

Un fondu de deux cents millisecondes ne gêne personne. Un glissement latéral appliqué à toute la page en gêne beaucoup, et le réglage système existe pour cela.

Où c’est utilisable

Chrome et Edge depuis la version 126, en mai 2024. Safari depuis la version 18.2, en décembre 2024 ; WebKit a titré son annonce sur les deux lignes de code utilisables dès aujourd’hui. Firefox a livré les transitions à l’intérieur d’une même page mais pas encore, en version stable, celles d’une page à l’autre. La table à jour est sur Can I Use.

La dégradation est ici la meilleure possible, et c’est l’argument décisif : un navigateur qui ne connaît pas @view-transition ignore la règle et navigue comme il l’a toujours fait. Il n’y a rien à prévoir, rien à tester en double, aucun script de secours. La page ne perd pas une fonction, elle perd un fondu.

Ce que cela change pour un site fabriqué en pages

L’argument du confort de navigation était le dernier argument technique sérieux en faveur d’une architecture pilotée par JavaScript pour un site de contenu. Il vient de tomber, pour deux lignes de CSS.

Restent les vrais cas d’usage de ces architectures, qui existent : un tableau de bord, un éditeur, un formulaire à état complexe. Un magazine, un site de présentation, un catalogue, une documentation n’en font pas partie et n’en ont jamais fait partie. Ils y allaient pour ne pas clignoter. Pour juger sur pièces, les titres du catalogue naviguent déjà avec ces transitions.