Utiliser JavaScript dès qu'un élément doit bouger sur une page, c’était la solution de facilité, mais c’est une habitude qui finit par alourdir les sites web et nous compliquer la vie pour la maintenance.

Le CSS moderne a tellement évolué qu'il gère désormais seul des interactions qu'on pensait réservées aux scripts complexes. On peut aujourd'hui presque tout faire sans ajouter de code inutile .

Pour une entreprise, une approche CSS-first est un levier stratégique qui permet de gagner en performance. 

Dans cet article, notre intégratrice Aurore nous explique pourquoi (et comment) prioriser le CSS pour vos projets web.

Ce que CSS peut faire aujourd'hui

Le CSS moderne a évolué bien au-delà de la simple mise en forme. Des fonctionnalités autrefois réservées à JavaScript sont désormais réalisables en pur CSS, offrant des interactions fluides sans une ligne de code JavaScript.

Les accordéons avec <details> et <summary>

La solution la plus simple et la plus accessible pour créer un accordéon est d'utiliser les éléments HTML natifs <details> et <summary>. Aucun JavaScript, aucun hack : juste du HTML sémantique que vous stylisez en CSS.

<details class="accordion-item">

  <summary class="accordion-header">

    Section 1

    <span class="icon">▼</span>

  </summary>

  <div class="accordion-content">

    <p>Contenu de la section qui s'affiche ou se cache.</p>

  </div>

</details>

.accordion-item {

  margin-bottom: 0.5rem;

  border: 1px solid #e5e7eb;

  border-radius: 8px;

}

.accordion-header {

  display: flex;

  align-items: center;

  justify-content: space-between;

  cursor: pointer;

  padding: 1rem;

  list-style: none;

  font-weight: 600;

}

/* Masquer le marqueur par défaut */

.accordion-header::-webkit-details-marker {

  display: none;

}

.accordion-content {

  animation: slideDown 0.3s ease;

  padding: 0 1rem 1rem;

}

.icon {

  transition: transform 0.3s ease;

}

details[open] .icon {

  transform: rotate(180deg);

}

@keyframes slideDown {

  from {

    transform: translateY(-10px);

    opacity: 0;

  }

  to {

    transform: translateY(0);

    opacity: 1;

  }

}

Pour des besoins plus avancés : le checkbox hack

Si vous avez besoin de comportements plus complexes (fermer automatiquement les autres accordéons quand on en ouvre un, ou contrôler l'état depuis le CSS parent avec :has()), le checkbox hack reste une alternative valable.

<div class="accordion-item">

  <input type="radio" id="section1" name="accordion" class="accordion-toggle" hidden>

  <label for="section1" class="accordion-header">

    Section 1

    <span class="icon">▼</span>

  </label>

  <div class="accordion-content">

    <p>Contenu de la section qui s'affiche ou se cache.</p>

  </div>

</div>

.accordion-item {

  margin-bottom: 0.5rem;

  border: 1px solid #e5e7eb;

  border-radius: 8px;

}

.accordion-header {

  display: flex;

  align-items: center;

  justify-content: space-between;

  cursor: pointer;

  padding: 1rem;

  list-style: none;

  font-weight: 600;

}

.accordion-content {

  transition: max-height 300ms ease, padding 300ms ease;

  padding-inline: 1rem;

  max-height: 0;

  overflow: hidden;

}

.accordion-toggle:checked ~ .accordion-content {

  padding-bottom: 1rem;

  max-height: 500px;

}

.accordion-item:has(.accordion-toggle:checked) .icon {

  transform: rotate(180deg);

}

.icon {

  transition: transform 300ms ease;

}

Les modales natives avec <dialog>

L'élément HTML <dialog> combiné au pseudo-élément ::backdrop permet de créer des modales accessibles sans bibliothèque. Le sélecteur :modal cible spécifiquement les dialogues ouverts en mode modal, tandis que ::backdrop style automatiquement l'overlay d'arrière-plan. L'accessibilité est gérée nativement : focus trap, fermeture à l'Échap, et gestion ARIA intégrée.

<button onclick="document.getElementById('myDialog').showModal()">

  Ouvrir la modale

</button>

<dialog id="myDialog">

  <h2>Titre de la modale</h2>

  <p>Contenu de la modale...</p>

  <button onclick="this.closest('dialog').close()">Fermer</button>

</dialog>

dialog {

  position: fixed;

  top: 50%;

  left: 50%;

  transform: translate(-50% -50%);

  border: none;

  border-radius: 8px;

  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);

  padding: 2rem;

  max-width: 500px;

}

dialog::backdrop {

  background: rgba(0, 0, 0, 0.5);

  backdrop-filter: blur(4px);

}

dialog:modal {

  animation: slideIn 0.3s ease;

}

@keyframes slideIn {

  from {

    opacity: 0;

  }

  to {

    opacity: 1;

  }

}

Les tooltips avec l'API Popover (Support partiel)

L'attribut popover transforme n'importe quel élément en tooltip ou menu contextuel. Couplé avec anchor-name et position-anchor, vous pouvez positionner précisément vos popovers par rapport à leurs déclencheurs, le tout géré par le navigateur. Le z-index et la couche supérieure sont automatiquement gérés.

Note : L'API Popover est supportée sur Chrome/Edge depuis 2023, Firefox depuis fin 2024, mais pas encore sur Safari. Le CSS Anchor Positioning est encore plus expérimental (Chrome uniquement pour le moment). Pour les navigateurs non compatibles, il faut prévoir un fallback.

html

<button popovertarget="info-tooltip" style="anchor-name: --trigger">

  Info

</button>

<div id="info-tooltip" popover>

  Ceci est un tooltip informatif

</div>

css

[popover] {

  position: fixed;

  position-anchor: --trigger;

  position-area: top right;

  margin-bottom: 0.5rem;

  border: none;

  border-radius: 4px;

  background-color: #333;

  padding: 0.5rem 1rem;

  color: white;

}

[popover]:popover-open {

  animation: fadeIn 0.2s ease;

}

@keyframes fadeIn {

  from { opacity: 0; }

  to { opacity: 1; }

}

Les animations au scroll (scroll-driven animations)

Les scroll-driven animations permettent de synchroniser des animations CSS avec la position de scroll. Vous pouvez créer des effets de parallaxe, des barres de progression, ou des animations révélant du contenu au fur et à mesure du défilement, le tout avec animation-timeline: scroll() ou view().

Note : Les scroll-driven animations sont actuellement supportées uniquement sur Chrome/Edge (depuis 2023) derrière un flag sur Firefox. Safari n'a pas encore d'implémentation. À utiliser avec progressive enhancement et un fallback approprié.

Voici le lien vers le site officiel des démos de scroll-driven animations.

<div class="progress-bar"></div>

<main>

  <section class="reveal">Contenu qui s'anime au scroll</section>

  <section class="reveal">Autre section</section>

</main>

css

/* Barre de progression en haut de page */

.progress-bar {

  position: fixed;

  top: 0;

  left: 0;

  transform-origin: left;

  animation: grow linear;

  animation-timeline: scroll(root);

  background: linear-gradient(to right, #4f46e5, #06b6d4);

  height: 4px;

}

@keyframes grow {

  from { transform: scaleX(0); }

  to { transform: scaleX(1); }

}

/* Révélation d'éléments au scroll */

.reveal {

  transform: translateY(50px);

  animation: reveal linear forwards;

  animation-timeline: view();

  animation-range: entry 0% cover 30%;

  opacity: 0;

}

@keyframes reveal {

  to {

    transform: translateY(0);

    opacity: 1;

  }

}

La gestion d'états avec les pseudo-classes

Les combinaisons de :checked, :focus-within, :target, et maintenant :has() créent des possibilités infinies. Un système de navigation à onglets peut être construit avec des radio buttons cachés, où chaque onglet est associé à un input. Le contenu affiché change selon l'input :checked, sans JavaScript.

HTML

<div class="tabs">

  <input type="radio" name="tabs" id="tab1" checked hidden>

  <input type="radio" name="tabs" id="tab2" hidden>

  <input type="radio" name="tabs" id="tab3" hidden>

  <nav class="tabs-nav">

    <label for="tab1">Onglet 1</label>

    <label for="tab2">Onglet 2</label>

    <label for="tab3">Onglet 3</label>

  </nav>

  <div class="tab-content" data-tab="1">Contenu 1</div>

  <div class="tab-content" data-tab="2">Contenu 2</div>

  <div class="tab-content" data-tab="3">Contenu 3</div>

</div>

CSS

.tab-content {

  display: none;

  padding: 1rem;

}

#tab1:checked ~ .tab-content[data-tab="1"],

#tab2:checked ~ .tab-content[data-tab="2"],

#tab3:checked ~ .tab-content[data-tab="3"] {

  display: block;

  animation: fadeIn 0.3s ease;

}

.tabs-nav label {

  transition: all 0.2s;

  border-bottom: 2px solid transparent;

  cursor: pointer;

  padding: 0.5rem 1rem;

}

#tab1:checked ~ .tabs-nav label[for="tab1"],

#tab2:checked ~ .tabs-nav label[for="tab2"],

#tab3:checked ~ .tabs-nav label[for="tab3"] {

  border-bottom-color: #4f46e5;

  color: #4f46e5;

}

Les avantages de l'approche CSS-first

Adopter une approche "CSS-first" pour l'interactivité n'est pas qu'une question de préférence technique, c'est un choix qui impacte directement la performance, l'accessibilité et la maintenabilité de vos projets.

Performance : moins de charge, plus de fluidité

Le JavaScript doit être téléchargé, parsé, compilé puis exécuté par le navigateur. Le CSS, lui, est interprété de manière déclarative par le moteur de rendu, un processus intrinsèquement plus rapide. En privilégiant CSS pour l'interactivité, vous réduisez le temps de blocage du thread principal, laissant le navigateur libre de répondre aux interactions utilisateur. Les animations CSS peuvent également être accélérées matériellement par le GPU, contrairement à de nombreuses animations JavaScript qui restent sur le CPU.

Sur mobile, où la puissance de calcul est limitée et la bande passante parfois faible, cette différence devient critique.

Accessibilité native et respect des préférences utilisateur

Le CSS offre un avantage souvent sous-estimé : le respect automatique des préférences système. La media query prefers-reduced-motion permet de désactiver ou réduire les animations pour les utilisateurs sensibles au mouvement, sans avoir à gérer cette logique manuellement en JavaScript. De même, prefers-color-scheme s'adapte automatiquement au thème sombre ou clair.

Les éléments HTML natifs comme <dialog>, <details>, ou les inputs viennent avec une accessibilité intégrée : gestion du focus, navigation clavier, annonces aux lecteurs d'écran. Quand vous les stylisez en CSS plutôt que de recréer leur comportement en JavaScript, vous préservez ces fonctionnalités gratuitement.

Progressive enhancement et résilience

Une interface construite en CSS-first fonctionne même si JavaScript échoue à charger, est bloqué par une extension, ou met du temps à s'initialiser. C'est le principe du progressive enhancement : votre contenu reste accessible et fonctionnel dans tous les cas, JavaScript venant ajouter une couche d'amélioration quand disponible.

Cette approche crée des sites plus résilients face aux conditions réseau dégradées, aux bloqueurs de scripts, ou aux erreurs JavaScript qui n'impactent pas le CSS. Votre accordéon construit avec <details> fonctionnera toujours, même si un script tiers plante votre page.

Moins de dépendances, moins de maintenance

Chaque bibliothèque JavaScript que vous ajoutez est une dépendance à maintenir : mises à jour de sécurité, migration vers de nouvelles versions, risque d'obsolescence. Le CSS, en tant que standard du web, évolue de manière rétrocompatible. Un accordéon écrit en CSS pur en 2026 fonctionnera toujours en 2036 sans modification.

Vous évitez également les problèmes de taille de bundle, ou de conflits entre versions de dépendances. Votre code devient plus léger, plus simple à auditer, et votre équipe n'a pas besoin de maîtriser un énième framework pour modifier un composant.

Meilleur pour le SEO et l'indexation

Les moteurs de recherche excellent à comprendre le HTML et le CSS, mais peuvent avoir des difficultés avec le contenu généré par JavaScript, notamment s'il nécessite des interactions pour apparaître. Un contenu directement présent dans le DOM, révélé par CSS, est immédiatement accessible aux crawlers.

De plus, les Core Web Vitals de Google pénalisent les sites avec un JavaScript bloquant important. En réduisant votre dépendance à JavaScript pour l'interactivité de base, vous améliorez naturellement vos scores de Largest Contentful Paint (LCP) et de First Input Delay (FID), deux métriques cruciales pour le référencement.

Un code plus déclaratif et lisible

Le CSS décrit ce qui doit se passer dans différents états, plutôt que comment le faire se produire. Cette approche déclarative rend souvent le code plus facile à comprendre et à maintenir. Comparez la lisibilité d'un sélecteur :has(.menu-open) versus une série de addEventListener et de manipulations de classes JavaScript.

Pour les designers et intégrateurs qui ne sont pas développeurs JavaScript, pouvoir créer de l'interactivité en restant dans leur domaine d'expertise CSS est un gain de productivité considérable.

Quand JavaScript devient nécessaire

Aussi puissant que soit devenu le CSS, il reste un langage de présentation et de style. Certaines fonctionnalités relèvent intrinsèquement de la logique applicative et nécessitent JavaScript. Reconnaître ces limites est essentiel pour ne pas tomber dans le piège du "CSS à tout prix".

Logique conditionnelle complexe

Le CSS peut gérer des états binaires (ouvert/fermé, actif/inactif) et des variations basées sur des sélecteurs, mais dès que vous devez évaluer plusieurs conditions interdépendantes, calculer des valeurs dynamiquement, ou prendre des décisions selon des règles métier, JavaScript devient indispensable.

Par exemple, afficher un message différent selon qu'un utilisateur a visité 3, 10 ou 50 fois le site, ou ajuster un comportement selon l'heure de la journée, nécessite une logique que le CSS ne peut pas exprimer. De même, la validation de formulaires avec des règles complexes (vérifier qu'un mot de passe contient au moins une majuscule, un chiffre, et fait 12 caractères) dépasse les capacités du CSS seul.

Interactions avec des APIs externes

Dès que vous devez communiquer avec un serveur, interroger une base de données, ou interagir avec des services tiers, JavaScript est incontournable. Le CSS ne peut pas faire de requêtes HTTP, parser du JSON, ou gérer des websockets.

Que ce soit pour charger du contenu dynamique, soumettre un formulaire en AJAX, récupérer des données depuis une API REST, ou synchroniser des informations en temps réel, vous sortez du domaine du CSS. L'authentification, la gestion de tokens, les cookies, tout cela relève exclusivement de JavaScript (côté client).

Manipulation dynamique du DOM

Créer, supprimer ou réorganiser des éléments HTML en fonction d'actions utilisateur nécessite JavaScript. Le CSS peut montrer ou cacher des éléments existants, mais ne peut pas en générer de nouveaux.

Si vous construisez une todo-list où l'utilisateur peut ajouter des tâches, un système de commentaires avec réponses imbriquées, ou un éditeur WYSIWYG, vous devez manipuler le DOM. De même, trier dynamiquement un tableau, filtrer une liste de résultats, ou paginer du contenu nécessite de modifier la structure HTML, ce qui est impossible en CSS pur.

Gestion d'état applicatif

Les applications web modernes maintiennent souvent un état complexe : données utilisateur, préférences, historique de navigation, panier... Cet état doit être partagé entre différents composants, synchronisé avec le serveur, et parfois persisté localement.

Le CSS peut refléter un état (via des classes ou des attributs), mais ne peut pas le gérer. Vous avez besoin de JavaScript pour stocker des données dans localStorage, gérer un store Redux ou Zustand, synchroniser l'état entre onglets.

Validation de formulaires avancée

Bien que HTML5 offre une validation basique (required, pattern, type="email"), et que CSS permette de styler les états :valid et :invalid, la validation complexe reste du domaine JavaScript.

Vérifier qu'un IBAN est valide, qu'une date de naissance correspond à un âge minimum, qu'un code postal existe réellement, ou afficher des messages d'erreur personnalisés en temps réel nécessite du code. De même, la validation asynchrone (vérifier si un nom d'utilisateur est déjà pris) requiert forcément JavaScript.

La frontière est claire : le CSS excelle pour la présentation, les états visuels et l'interactivité simple. JavaScript prend le relais dès que vous entrez dans le domaine de la logique métier, de la communication réseau, ou de la manipulation de données. L'art consiste à utiliser chacun là où il brille.

L'approche hybride intelligente

La vraie question n'est pas "CSS ou JavaScript", mais "comment les combiner intelligemment". L'approche hybride consiste à tirer parti des forces de chaque technologie, en commençant par une base CSS solide et en ajoutant JavaScript uniquement là où il apporte une valeur réelle.

Le principe : commencer par CSS, enrichir avec JavaScript

La stratégie gagnante est de construire d'abord une version fonctionnelle en HTML et CSS, puis d'identifier les points où JavaScript améliorerait réellement l'expérience. Cette approche garantit que votre interface reste utilisable même si JavaScript échoue, tout en permettant des expériences enrichies pour ceux qui en bénéficient.

Concrètement, cela signifie : créer vos états visuels en CSS, vos transitions et animations en CSS, votre structure de base en HTML sémantique. JavaScript intervient ensuite pour ajouter de la logique métier, des interactions avec le serveur, ou des comportements impossibles en CSS pur.

Utiliser les data-attributes comme pont entre CSS et JavaScript

Les attributs de données (data-*) constituent un excellent moyen de communication entre CSS et JavaScript. Ils permettent à JavaScript de modifier l'état d'un composant en changeant un simple attribut, tandis que CSS réagit à ce changement via des sélecteurs.

Cette séparation des responsabilités rend le code plus maintenable : JavaScript gère la logique ("quand l'utilisateur fait X, l'état devient Y"), tandis que CSS gère la présentation ("quand l'état est Y, afficher de telle manière"). Vous évitez ainsi la manipulation directe de styles en JavaScript, qui crée un couplage fort et rend le code difficile à modifier.

Par exemple, plutôt que d'ajouter/retirer des classes ou de modifier style.display en JavaScript, vous changez un attribut data-state, et c'est CSS qui définit l'apparence de chaque état. Cette approche facilite également les tests : vous pouvez tester votre logique JavaScript indépendamment du rendu visuel.

Web Components : le meilleur des deux mondes

Les Web Components offrent une architecture idéale pour l'approche hybride. Ils encapsulent HTML, CSS et JavaScript dans des composants réutilisables, avec une séparation claire des responsabilités.

Le Shadow DOM permet d'isoler les styles CSS, évitant les conflits globaux. La logique JavaScript gère les interactions et l'état interne du composant, tandis que CSS assure la présentation. Les slots permettent de composer des interfaces flexibles, et les custom events facilitent la communication entre composants.

Cette architecture favorise naturellement une approche où CSS gère tout ce qu'il peut gérer, JavaScript n'intervenant que pour la logique spécifique au composant. De plus, les Web Components sont des standards web, sans dépendance à un framework particulier.

Exemple concret : un système de tabs intelligent

Prenons l'exemple d'un système d'onglets. La version CSS-only utilise des radio buttons cachés et fonctionne parfaitement pour des cas simples. Mais que se passe-t-il si vous devez :

• Charger le contenu d'un onglet via AJAX uniquement quand il est activé
• Sauvegarder l'onglet actif dans l'URL pour permettre le partage
• Précharger le contenu du prochain onglet probable
• Logger les interactions pour l'analytics

C'est là qu'une approche hybride brille. La structure de base et les états visuels restent gérés en CSS, garantissant que les onglets sont cliquables et fonctionnels même sans JavaScript. JavaScript vient ensuite enrichir l'expérience : il intercepte les changements d'onglets, met à jour l'URL, déclenche les requêtes AJAX nécessaires, et envoie les événements analytics.

L'utilisateur sans JavaScript voit tous les contenus d'emblée (ou via des liens vers des pages distinctes), celui avec JavaScript bénéficie du chargement lazy et de la persistance dans l'URL. Progressive enhancement à l'état pur.

L'équilibre entre simplicité et fonctionnalité

L'approche hybride demande du discernement. Il faut résister à la tentation d'ajouter JavaScript "au cas où" ou "parce qu'on peut". Chaque ligne de JavaScript ajoutée est une ligne à maintenir, à tester, et potentiellement à debugger.

Posez-vous systématiquement la question : "Que se passe-t-il si ce JavaScript ne se charge pas ?" Si la réponse est "l'interface devient inutilisable", vous avez probablement trop misé sur JavaScript. Si la réponse est "l'utilisateur perd quelques fonctionnalités avancées mais peut accomplir sa tâche", vous êtes sur la bonne voie.

Gérer la transition progressive

Dans un projet existant avec beaucoup de JavaScript, la transition vers une approche CSS-first peut se faire progressivement. Identifiez les composants simples (dropdowns, tooltips, accordéons) et remplacez-les un par un par des versions CSS-first.

Commencez par les nouveaux composants : construisez-les directement avec cette philosophie. Documentez vos choix pour que l'équipe comprenne la logique et puisse la reproduire. Avec le temps, votre codebase deviendra plus légère, plus performante et plus résiliente.

L'approche hybride n'est pas un compromis mou, c'est une stratégie délibérée qui maximise les atouts de chaque technologie. Elle demande de la réflexion et de la discipline, mais produit du code plus robuste et plus maintenable.

Les pièges à éviter

L'approche CSS-first est séduisante, mais elle peut conduire à des dérives si on la pousse à l'extrême sans discernement. Voici les erreurs courantes qui transforment une bonne idée en cauchemar de maintenance.

Surcharger CSS avec des hacks non maintenables

La tentation est grande, une fois qu'on découvre les possibilités du CSS moderne, de vouloir tout résoudre avec. Mais certains "hacks" CSS, bien que impressionnants techniquement, deviennent rapidement incompréhensibles pour le reste de l'équipe.

Les checkbox hacks avec 15 niveaux de sélecteurs imbriqués, les combinaisons obscures de :nth-child() pour simuler de la logique conditionnelle, ou les animations CSS qui tentent de reproduire des comportements complexes : ces solutions finissent par créer plus de problèmes qu'elles n'en résolvent.

Si vous devez ajouter un commentaire de 20 lignes pour expliquer comment fonctionne votre CSS, ou si modifier un comportement nécessite de toucher à 10 sélecteurs différents, c'est probablement le signe qu'une simple fonction JavaScript de 5 lignes serait plus appropriée. La lisibilité et la maintenabilité doivent primer sur la prouesse technique.

Sacrifier l'accessibilité pour éviter JavaScript

C'est sans doute le piège le plus dangereux. Sous prétexte d'éviter JavaScript, on peut être tenté de créer des "faux" éléments interactifs : des divs cliquables stylées comme des boutons, des spans qui réagissent au hover pour afficher du contenu, ou des constructions complexes qui ne respectent pas la sémantique HTML.

L'ironie est totale : on pense améliorer l'accessibilité en évitant JavaScript, mais on la détruit en créant des interfaces que les technologies d'assistance ne peuvent pas interpréter. Un vrai bouton avec un simple addEventListener sera toujours plus accessible qu'une div avec un onclick CSS simulé via :target.

Les utilisateurs au clavier doivent pouvoir naviguer, les lecteurs d'écran doivent annoncer correctement les éléments, les zones interactives doivent avoir la bonne taille pour le tactile. Si votre solution CSS-only ne respecte pas ces principes, elle n'a aucune valeur, aussi élégante soit-elle techniquement.

Réinventer la roue quand une bibliothèque légère suffit

Il y a une différence entre éviter les dépendances inutiles et refuser par principe toute bibliothèque. Parfois, une bibliothèque JavaScript de 2-3Ko bien maintenue, testée sur tous les navigateurs, et utilisée par des millions de développeurs, est un meilleur choix qu'une solution CSS maison fragile.

Le datepicker est l'exemple typique : créer un calendrier accessible, internationalisé, avec navigation clavier, support des fuseaux horaires, et validation des dates en pur CSS est quasi impossible. Utiliser une bibliothèque éprouvée n'est pas un échec, c'est du pragmatisme.

Ignorer les problèmes de performance du CSS

On présente souvent CSS comme intrinsèquement plus performant que JavaScript, mais ce n'est vrai que si le CSS est bien écrit. Des sélecteurs trop complexes peuvent ralentir le rendu, surtout sur mobile. Un :has() imbriqué sur des milliers d'éléments peut être plus lent qu'un simple gestionnaire d'événements JavaScript.

Les animations CSS ne sont GPU-accelerated que si elles utilisent les bonnes propriétés (transform, opacity). Animer width, height, ou top/left force des reflows coûteux. Dans ces cas, une animation JavaScript bien optimisée avec requestAnimationFrame peut être plus performante.

De même, multiplier les transitions CSS sur tous les éléments d'une page "au cas où" surcharge le navigateur. Soyez sélectif : animez ce qui doit l'être, pas tout par défaut.

Négliger le support navigateur et le progressive enhancement

Utiliser les dernières fonctionnalités CSS sans vérifier le support ni prévoir de fallback transforme votre site en exclusivité pour Chrome. Les scroll-driven animations qui ne fonctionnent pas sur Safari, les anchor-positioning qui cassent tout sur Firefox : votre CSS-first devient CSS-only-for-some.

L'approche CSS-first doit s'accompagner de progressive enhancement : une base fonctionnelle pour tous, des améliorations pour ceux qui peuvent en profiter. Utilisez @supports, prévoyez des alternatives, testez sur plusieurs navigateurs. Sinon, vous n'avez fait que déplacer le problème : au lieu d'exclure les utilisateurs sans JavaScript, vous excluez ceux avec de vieux navigateurs.

L'approche CSS-first est un outil, pas une religion. Elle doit servir vos utilisateurs et votre équipe, pas votre désir de prouesse technique. Savoir reconnaître quand s'arrêter et passer à JavaScript est une compétence aussi importante que de savoir pousser CSS dans ses retranchements.

Conclusion : L'équilibre plutôt que le dogmatisme

Le débat "CSS first vs JavaScript" n'est pas une guerre à gagner, mais un équilibre à trouver. Le CSS moderne offre des possibilités d'interactivité impressionnantes, nous libérant pour utiliser JavaScript là où il apporte une réelle valeur : logique métier, communication serveur, manipulation de données, gestion d'état.

La vraie compétence consiste à reconnaître quel outil convient à quel problème. Un accordéon simple ? CSS pur. Une application complexe avec synchronisation temps réel ? JavaScript a tout son sens. Entre les deux, une infinité de nuances où votre jugement fait la différence.

Le web n'a pas besoin de puristes CSS ou de fanatiques JavaScript, mais de développeurs pragmatiques qui construisent des expériences robustes, accessibles et performantes pour tous.

Vous avez en tête un projet de refonte ou une interface à optimiser ? Contactez nos équipes pour en discuter ! On sera ravis de vous accompagner sur vos projets.