View Transitions API et dark mode propre : guide 2026

Pendant des années, les transitions entre pages et le dark mode reposaient sur du JavaScript lourd. En 2026, CSS reprend la main. La View Transitions API offre des transitions natives entre vues et entre URLs. Les fonctions `color-scheme`, `prefers-color-scheme` et `light-dark()` permettent de gérer le thème sombre sans toggle JavaScript. Ce guide détaille comment combiner ces outils pour livrer un site moderne, performant et accessible, sans dépendance externe.

View Transitions API : qu’est-ce que c’est ?

La View Transitions API est une interface CSS et JavaScript qui anime le passage d’un état du DOM à un autre. Le navigateur capture l’ancien état, capture le nouveau, puis fait un crossfade entre les deux. Vous personnalisez les animations via des pseudo-éléments CSS.

Selon la documentation officielle MDN, l’API gère deux scénarios distincts : les transitions au sein d’un même document (Single Page App) et les transitions entre documents (navigation classique multi-pages).

Le bénéfice est double. Côté développeur, plus besoin de bibliothèques type Framer Motion ou GSAP pour des transitions de base. Côté utilisateur, l’expérience devient cohérente avec une app native, sans surcoût de bundle.

Same-document vs Cross-document : deux usages distincts

L’API existe en deux variantes, avec une chronologie différente.

Same-document : disponible en stable dans Chrome 111 depuis mars 2023, comme le rappelle la release notes Chrome. Cette variante s’utilise dans les Single Page Apps (React, Vue, Svelte) qui modifient le DOM sans recharger la page. L’appel se fait en JavaScript via `document.startViewTransition()`.

Cross-document : stabilisé dans Chrome 126 en juin 2024. Cette variante anime les transitions entre deux URLs différentes du même origine. Aucun JavaScript requis, tout se déclare en CSS. C’est le cas d’usage parfait pour un site WordPress multi-pages.

Variante	Stable Chrome	Stable Safari	Usage type
Same-document	111 (mars 2023)	18.0 (sept. 2024)	Single Page Apps
Cross-document	126 (juin 2024)	18.2 (déc. 2024)	Sites multi-pages, WordPress

Pour un blog ou un site vitrine WordPress, la version cross-document change vraiment la donne. Vous obtenez des transitions natives sans toucher au JavaScript.

Comment activer View Transitions sur un site WordPress multi-pages ?

L’activation se fait en deux étapes : déclarer la règle CSS, puis définir les animations.

Première étape, dans la feuille de style du thème (ou dans `theme.json` via `additionalCSS`) :

“`css @view-transition { navigation: auto; } “`

Cette règle indique au navigateur d’activer les transitions pour toute navigation same-origin. La documentation Chrome précise que les deux pages (départ et arrivée) doivent opt-in pour que la transition se déclenche.

Deuxième étape, personnaliser les animations via des pseudo-éléments :

“`css ::view-transition-old(root) { animation: fade-out 0.3s ease-in-out; } ::view-transition-new(root) { animation: fade-in 0.3s ease-in-out; }

@keyframes fade-out { to { opacity: 0; } } @keyframes fade-in { from { opacity: 0; } } “`

Le résultat est un fondu enchaîné natif entre les pages. Pour aller plus loin, vous pouvez nommer des éléments précis avec `view-transition-name`, par exemple animer une image qui change de taille entre deux pages.

Côté WordPress, intégrez ce CSS dans le thème (Etch, Bricks, GeneratePress, etc.) ou via le bloc « CSS personnalisé » de la customizer. Aucun plugin n’est nécessaire. Notre comparatif des builders WordPress (Etch, Bricks, Breakdance, Elementor) détaille les builders qui exposent proprement ces réglages CSS.

Limitations actuelles : Safari et Firefox

L’écosystème navigateurs progresse, mais reste hétérogène en mai 2026.

Safari supporte les transitions same-document depuis la version 18.0 (septembre 2024). La variante cross-document est arrivée dans Safari 18.2 en décembre 2024.

Firefox a stabilisé les transitions same-document à partir de la version 144. La variante cross-document reste en cours d’implémentation et n’est pas encore disponible en stable.

Concrètement, sur un site WordPress cross-document en 2026 :

• Chrome, Edge, Brave, Opera : transitions actives.
• Safari 18.2+ : transitions actives.
• Firefox stable : pas de transition, comportement de navigation classique.

C’est exactement le bon profil d’une amélioration progressive. Le navigateur sans support ignore la règle `@view-transition` et affiche la page sans animation. Aucun fallback JavaScript n’est nécessaire. Cette élégance native est une raison majeure de privilégier CSS plutôt que des libs côté client.

Pour suivre l’évolution du support, caniuse.com reste la référence à jour.

Dark mode propre : au-delà du simple toggle

Le dark mode ne se résume pas à inverser le noir et le blanc. Un dark mode propre suit trois principes.

Premier principe, respecter la préférence système par défaut. L’utilisateur qui a activé le mode sombre sur son OS s’attend à le retrouver partout. Forcer un mode clair brille mal sur un écran OLED à 23h.

Deuxième principe, éviter le noir pur. Le contraste #FFF sur #000 fatigue. Les guides 2026 recommandent des gris foncés comme `#121212` ou `#1A1A1A`, et des blancs cassés comme `#E0E0E0` pour le texte.

Troisième principe, proposer un toggle manuel. Certains utilisateurs préfèrent override leur OS. Le toggle stocke le choix dans `localStorage` et l’applique via une classe sur ``.

Ce trio (système, palette, toggle) constitue la base d’un dark mode professionnel. Voyons maintenant le code.

color-scheme CSS et prefers-color-scheme : les bases

La propriété `color-scheme` annonce au navigateur les modes supportés par la page. Sans cette déclaration, les éléments natifs (barres de scroll, sélecteurs de date, champs de formulaire) restent en mode clair même si vous styliez le reste de la page en sombre.

“`css :root { color-scheme: light dark; } “`

Cette ligne suffit pour que le navigateur adapte les widgets natifs. C’est la base du dark mode propre.

La média query `prefers-color-scheme` détecte la préférence OS de l’utilisateur. Elle s’utilise pour servir un thème sombre par défaut :

“`css :root { –bg: #ffffff; –text: #1a1a1a; }

@media (prefers-color-scheme: dark) { :root { –bg: #121212; –text: #e0e0e0; } }

body { background: var(–bg); color: var(–text); } “`

Selon MDN, cette média query est supportée par tous les navigateurs modernes depuis 2020. Aucun JavaScript requis, aucune dépendance, aucun flash de contenu mal stylé si vous chargez le CSS dans le ``.

light-dark() : la fonction CSS qui simplifie tout

La fonction `light-dark()`, arrivée en stable dans Chrome 123 (avril 2024), Safari 17.5 (mai 2024) et Firefox 120 (novembre 2023), simplifie le code dark mode. Elle prend deux valeurs : une pour le mode clair, une pour le mode sombre. Le navigateur choisit selon la préférence active.

Avant `light-dark()` :

“`css :root { –bg: #ffffff; –text: #1a1a1a; } @media (prefers-color-scheme: dark) { :root { –bg: #121212; –text: #e0e0e0; } } “`

Avec `light-dark()` :

“`css :root { color-scheme: light dark; –bg: light-dark(#ffffff, #121212); –text: light-dark(#1a1a1a, #e0e0e0); } “`

Une seule déclaration au lieu de deux blocs. Le code reste lisible quand vous gérez 15 ou 20 variables.

Attention, `light-dark()` exige que `color-scheme` soit déclaré sur l’élément (ou un parent). Sinon, la fonction ne sait pas quel mode appliquer.

Côté support, le statut Baseline « widely available » est attendu pour fin 2026 selon caniuse. En attendant, prévoyez un fallback pour les anciens navigateurs.

Variables CSS et dark mode : pattern recommandé

Le pattern le plus robuste combine variables CSS, `color-scheme`, `light-dark()` et un override manuel via attribut.

“`css :root { color-scheme: light dark; –bg: light-dark(#ffffff, #121212); –text: light-dark(#1a1a1a, #e0e0e0); –accent: light-dark(#0066cc, #4d9fff); –border: light-dark(#e5e5e5, #333333); }

[data-theme=”light”] { color-scheme: light; } [data-theme=”dark”] { color-scheme: dark; }

body { background: var(–bg); color: var(–text); } “`

Côté JavaScript, un toggle minimal :

“`js const toggle = document.querySelector(‘#theme-toggle’); toggle.addEventListener(‘click’, () => { const current = document.documentElement.dataset.theme; const next = current === ‘dark’ ? ‘light’ : ‘dark’; document.documentElement.dataset.theme = next; localStorage.setItem(‘theme’, next); });

const saved = localStorage.getItem(‘theme’); if (saved) document.documentElement.dataset.theme = saved; “`

Ce pattern donne le meilleur des deux mondes : préférence OS respectée par défaut, override manuel persistant, widgets natifs cohérents, zéro flash au chargement. Pour aller plus loin sur le CSS moderne et fluide, voir notre guide CSS clamp.

Combiner View Transitions et dark mode pour un site moderne

L’intérêt de coupler les deux technologies est concret : un site WordPress qui change de thème sans rechargement, avec une transition fluide entre clair et sombre.

Vous pouvez animer le passage de thème via la View Transitions API même au sein d’une seule page :

“`js function toggleTheme() { if (!document.startViewTransition) { applyTheme(); return; } document.startViewTransition(() => applyTheme()); }

function applyTheme() { const current = document.documentElement.dataset.theme; document.documentElement.dataset.theme = current === ‘dark’ ? ‘light’ : ‘dark’; } “`

Côté CSS, vous personnalisez la transition :

“`css ::view-transition-old(root), ::view-transition-new(root) { animation-duration: 0.4s; mix-blend-mode: normal; } “`

Le résultat est un fondu enchaîné natif entre les deux thèmes, sans library, sans `requestAnimationFrame` manuel. Sur un site WordPress moderne, cette combinaison apporte une signature visuelle élégante. Les tendances web design 2026 (animations, dark mode, CSS natif) confirment cette bascule vers le CSS natif et la réduction des dépendances.

Accessibility : prefers-reduced-motion et contraste

Une transition fluide ne doit jamais nuire à l’accessibilité. Deux règles WCAG s’appliquent.

Première règle, respecter `prefers-reduced-motion`. Cette média query détecte les utilisateurs qui ont demandé de réduire les animations dans leur OS. Elle répond au critère WCAG 2.3.3 selon la spécification W3C.

“`css @media (prefers-reduced-motion: reduce) { ::view-transition-old(root), ::view-transition-new(root) { animation: none; } *, *::before, *::after { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; } } “`

Cette règle désactive les animations View Transitions et toutes les autres pour les utilisateurs sensibles. Sans elle, vous pouvez provoquer des nausées vestibulaires (plus de 70 millions de personnes concernées dans le monde). Côté performance, un fondu CSS natif évite les régressions de LCP, CLS et INP mesurées par les Core Web Vitals 2026, contrairement à une lib JS lourde.

Deuxième règle, vérifier les contrastes en dark mode. Le ratio WCAG AA exige 4.5:1 pour le texte courant, 3:1 pour les gros titres. Un texte gris clair sur fond gris foncé peut tomber sous le seuil. Testez avec un outil comme axe DevTools ou les outils Chrome intégrés.

Pour un site WordPress accessible, voir notre guide création WordPress qui détaille la conformité RGAA.

Questions fréquentes

Conclusion

La View Transitions API et le trio `color-scheme` + `prefers-color-scheme` + `light-dark()` redéfinissent les standards du web design en 2026. Le CSS natif remplace des bibliothèques JavaScript entières. Les transitions deviennent fluides sans coût bundle. Le dark mode se gère en quelques lignes au lieu de centaines. Sur un site WordPress moderne, ce changement est immédiat : meilleure performance, meilleure accessibilité, signature visuelle plus pro. Pour démarrer, ajoutez `@view-transition { navigation: auto; }` et `color-scheme: light dark` à votre feuille de style, puis itérez sur la personnalisation. Pour aller plus loin, notre guide 10 astuces site internet réussi recense les bonnes pratiques complémentaires.