Remplacer un observateur JavaScript par quelques lignes de CSS, c'est tentant. Moins de code, moins de dépendances, et une logique confiée au navigateur. Sauf qu'une semaine après la mise en production, on découvre qu'une carte disparaît quelque part sur un tableau de bord, que le titre change de taille à une largeur « bizarre », ou que les marges d'un commentaire ne sont plus respectées. Le nouveau CSS a l'air simple. Le système, lui, l'est rarement.
C'est le piège classique des migrations vers les fonctionnalités modernes : une règle peut simplifier le code à un endroit, tout en rendant plus difficiles à suivre les interactions ailleurs. Le sujet n'est pas « CSS est trop puissant » ni « il faut revenir au JavaScript ». La vraie question, c'est : qui possède le comportement ? Qu'est-ce que la nouvelle règle change autour d'elle ? Et comment vérifier que le coût réel a baissé, pas seulement que le diff est plus court ?
Voici une méthode pour évaluer une migration avec des container queries, :has() ou l'imbrication CSS. L'objectif est simple : repérer les comportements à double commande, les effets de mise en page, les conflits de cascade et les régressions de performance avant que ça ne se transforme en ticket flou « ça marche chez moi ».
Pourquoi moins de code ne signifie pas moins de complexité
Une petite différence de code ne dit pas tout. Remplacer un bloc JavaScript par une règle CSS peut rendre un fichier plus léger, mais le rendu dépend aussi du DOM, du layout parent, de la cascade et des règles de calcul du navigateur.
Il vaut mieux séparer deux notions :
- La simplicité locale : combien il faut de lignes, d'éléments ou de conditions dans un fichier ou un composant.
- La complexité du système : combien de choses quelqu'un doit comprendre pour modifier le comportement sans déclencher d'effet de bord.
Une migration est vraiment simplificatrice seulement si elle améliore les deux. Dans un projet existant, ce n'est pas automatique. Le code historique est rarement « proprement rangé » dans un seul endroit : une classe peut être ajoutée par un script, ciblée par plusieurs sélecteurs, et dépendre d'un ordre d'import particulier.
Une fonctionnalité native rejoint un environnement existant
Prenons une carte qui passe en deux colonnes quand elle a assez de largeur. Une première approche peut utiliser ResizeObserver pour ajouter une classe, puis des sélecteurs associés pour changer la grille et la taille du titre. Une container query permet ensuite de déclarer la contrainte de largeur directement en CSS. Sur le papier, c'est plus direct.
Mais si on ajoute la règle CSS sans supprimer l'observateur, on obtient deux mécanismes qui « pilotent » le même état. Tant que les seuils coïncident, personne ne voit le doublon. Le jour où le seuil change d'un côté mais pas de l'autre, le titre peut prendre le style de « carte large » tandis que le contenu reste en une colonne.
La différence ne se situe donc pas entre « ancien JavaScript » et « nouveau CSS ». Elle se situe entre un comportement avec un propriétaire clair et un comportement où plusieurs mécanismes peuvent produire des états contradictoires.
Le bon critère de décision
Avant de valider une réécriture, posez-vous cette question : quels éléments et quelles règles faut-il connaître pour expliquer le rendu après ce changement ?
Si votre réponse implique un script résiduel, une classe restante, un sélecteur large et un comportement de conteneur, alors le diff n'a pas supprimé la complexité. Il l'a juste déplacée.
Une fonctionnalité native est un vrai gain quand elle remplace l'ancien mécanisme, reste dans son domaine de responsabilité, et ne modifie pas involontairement les composants voisins. Moins de lignes, ce n'est qu'un indice. Pas une preuve.
Comment éviter que CSS et JavaScript pilotent le même comportement
CSS et JavaScript peuvent coexister sans souci dans un composant. Le problème arrive quand ils prennent tous les deux la même décision. Une règle utile : donner un propriétaire explicite à chaque type d'état, puis supprimer l'ancienne implémentation lors de la migration.
Répartir les responsabilités
En général, CSS sert bien les décisions de présentation déduites de la taille ou de la structure du DOM : la disposition d'une carte selon son conteneur, le style d'un formulaire quand un champ est invalide, ou l'adaptation d'un composant à son contexte visuel.
JavaScript, lui, garde plutôt sa place pour l'état applicatif et les opérations asynchrones : requête en attente, réponse serveur, valeur dont d'autres parties du code dépendent, ou interaction qui déclenche une logique métier. Une règle CSS peut refléter un état exposé dans le DOM, mais elle ne devrait pas devenir une seconde source de vérité sur cet état.
Ce n'est pas une loi universelle : il existe des cas où une présentation dépend d'une donnée métier, et l'architecture du projet compte. L'objectif reste le même : que l'équipe sache répondre clairement à où est calculée la décision, et quel mécanisme fait autorité ?
Terminer la migration, pas seulement ajouter la nouvelle règle
Parfois, une migration en plusieurs étapes est nécessaire pour réduire le risque. Mais la cohabitation doit être assumée comme temporaire. Sinon, on fabrique une double commande permanente.
À la fin du chantier, cherchez et retirez ce qui ne sert plus :
- l'observateur ou le gestionnaire d'événement qui pilotait l'ancien comportement ;
- la classe ajoutée par JavaScript ;
- les sélecteurs qui ciblent cette classe ;
- les anciens seuils media queries ou container queries ;
- les tests et commentaires qui décrivent encore la logique précédente.
Une vérification pratique : retrouver le nom de la classe dans tout le dépôt, puis tester les états juste avant et juste après le seuil. Dans l'exemple de la carte, testez la zone de rupture des deux côtés, pas seulement une fenêtre très étroite et une fenêtre très large. Les états intermédiaires sont souvent ceux que le code n'a jamais explicitement prévus.
Quels effets une container query peut-elle avoir sur la mise en page
container-type: inline-size ne fait pas que rendre possibles des requêtes sur la largeur du conteneur. Comme le rappelle la documentation MDN, cette déclaration crée des mécanismes de confinement. Elle peut aussi introduire un nouveau contexte de formatage de bloc. Résultat : des comportements de mise en page changent, parfois sans rapport direct avec le seuil de la container query.
Vérifier les marges et les flottants
Le contexte de formatage de bloc peut, par exemple, empêcher certaines marges de fusionner, contenir les flottants internes, ou empêcher un flottant « extérieur » d'influencer la boîte comme avant.
Concrètement : une marge de paragraphe de 16 pixels et une marge supérieure de titre de 24 pixels, qui donnaient auparavant un espace fusionné de 24 pixels, peuvent maintenant s'additionner jusqu'à 40 pixels. Un bloc qui suivait un élément flottant peut aussi se décaler à côté plutôt que de s'étendre sous son empreinte.
Ce sont des effets de contexte, pas forcément des « bugs du navigateur ». Et si le composant est réutilisé ailleurs, son rendu isolé ne montrera pas le problème. Il faut le tester dans les vraies structures qui l'hébergent : grilles, flexbox, contenu éditorial, voisinage d'un flottant, et marges sur les premiers ou derniers enfants.
Anticiper l'effondrement d'un élément ajusté à son contenu
Le confinement de taille peut aussi empêcher un élément de déduire sa largeur de son contenu. Si le contexte ne lui fournit pas de largeur explicite (ou une largeur exploitable), certains éléments « ajustés au contenu » peuvent se réduire fortement, voire afficher une largeur nulle.
C'est particulièrement trompeur quand une carte semble « fonctionner seule » : en réalité, elle peut être un élément flex, une grille à pistes automatiques, ou un bloc dont la largeur dépend de ses enfants. Une carte qui « disparaît » dans un tableau de bord n'est pas forcément masquée par un display: none. Elle peut simplement ne plus avoir la largeur attendue.
Avant d'ajouter container-type, vérifiez :
- D'où vient la largeur ? Si elle dépend du contenu, fournissez une largeur via le contexte ou placez le conteneur de requête sur un wrapper dont la largeur est déjà déterminée.
- Les enfants ont-ils des marges ? Les marges qui fusionnaient avec l'extérieur peuvent rester dans la boîte.
- Où le composant est-il utilisé ? Testez les mises en page de production, pas uniquement une page de démo isolée.
La réponse n'est pas toujours « ajouter width: 100% ». Un wrapper peut être plus sûr si vous devez préserver le comportement actuel de la boîte visuelle. Le bon choix dépend de l'origine de la largeur et de la manière dont le composant s'insère dans le layout parent.
Comment maîtriser la cascade avec :has() et l'imbrication
:has() et l'imbrication native donnent de meilleures possibilités pour écrire des règles. Mais une syntaxe plus courte ne garantit ni une portée réduite, ni une spécificité faible. Un sélecteur « trop large » peut toucher plus d'éléments que prévu et battre une règle locale pourtant pertinente.
Réduire la portée des sélecteurs
Prenons une carte dont les paragraphes doivent perdre leur marge quand elle contient une image principale. La règle .card:has(img) p correspond à l'idée de départ. Sauf que :has(img) détecte aussi des éléments imbriqués : par exemple l'avatar d'un commentaire placé dans la carte. Et le p final cible tous les paragraphes descendants, y compris ceux du commentaire.
Le problème n'apparaît souvent qu'après ajout de contenu : comme la condition dépend du DOM, le diagnostic devient pénible. La règle n'est pas censée viser le commentaire, mais elle s'y applique à cause de la structure.
Le bon réflexe : borner le sélecteur à ce qui existe vraiment dans le DOM. Les combinateurs d'enfant direct > peuvent empêcher la traversée des composants imbriqués : .card:has(> img) > p. Attention : cette variante n'a de sens que si l'image principale et les paragraphes sont bien des enfants directs dans votre balisage. Le sélecteur doit refléter le DOM réel, pas une structure supposée.
Comprendre la spécificité héritée
:has() ne donne pas une spécificité « fixe » par défaut : la spécificité de son argument compte dans le calcul. Et avec l'imbrication native, & reprend la spécificité la plus élevée de la liste de sélecteurs concernée, comme décrit par MDN.
Une règle imbriquée dans une structure incluant un identifiant peut donc peser davantage qu'on ne l'imagine. Le correctif intuitif consiste souvent à ajouter encore plus de spécificité. Ça marche parfois à court terme, mais ça finit en empilement d'exceptions et en changements plus risqués.
Pour réduire ce poids, :where() est utile : il garde la condition de sélection tout en rendant la spécificité nulle. Ce n'est pas un réflexe à appliquer partout, mais un outil de conception. La première étape, elle, reste de limiter la portée au composant et à ses enfants réellement concernés.
Ne pas supposer que les couches règlent tout
Les @layer clarifient l'ordre entre familles de styles. Mais une feuille « partiellement migrée » peut aussi créer de nouvelles surprises. Selon MDN, les styles normaux non placés dans une couche ont priorité sur des styles normaux placés dans une couche, avant même la comparaison de spécificité.
Donc : mettre des nouveaux styles dans @layer components ne garantit pas qu'ils « gagnent » face à une règle historique restée hors couche. Les couches fonctionnent si les règles concurrentes suivent une stratégie cohérente. Dans un système ancien, ajouter une couche isolée peut juste ajouter un ordre de priorité supplémentaire à mémoriser.
Avant de valider un sélecteur, vérifiez sa portée, sa spécificité, les couches concernées, et les règles historiques qui ciblent déjà les mêmes éléments. DevTools peut montrer quelles déclarations gagnent, mais encore faut-il inspecter le composant dans l'état où le problème apparaît.
Comment tester les performances et sécuriser une migration
Déplacer du travail de JavaScript vers CSS change l'endroit où le navigateur calcule une décision. Ça ne prouve pas que le volume de travail baisse. Le coût dépend du sélecteur, des propriétés modifiées, du nombre d'éléments concernés, des mutations du DOM, et de la manière dont les règles interagissent.
Mesurer le scénario réel, pas une intuition
Un exemple publié d'analyse source compare plusieurs règles sur une liste de 5 000 lignes, dans Chrome 153 sur Mac, en octobre 2026. Le test bascule 300 fois une classe de sélection et observe les recalculs de style. Une règle body:has(.row.is-selected) prend environ 1,4 milliseconde par bascule dans ce scénario et ne restyle qu'un élément. Une seconde règle :has() paraît inoffensive seule, mais combinée à la première, elle entraîne le recalcul de 5 001 éléments et environ 7 millisecondes par bascule.
Avec 20 000 lignes, la combinaison monte à environ 31 millisecondes par bascule dans le même test. Ces chiffres ne servent pas de « règle générale » : tout dépend du navigateur, de la machine, du DOM et des sélecteurs exacts. Le point à retenir, c'est surtout que quelque chose de peu coûteux isolément peut devenir un vrai problème une fois combiné.
Donc : gardez le motif, pas le chiffre. Le moteur change selon les navigateurs. Une mesure dans Chrome est utile, mais ne suffit pas à conclure pour tous les navigateurs utilisés par vos clients.
Organiser une comparaison avant/après
Pour une interaction sensible, enregistrez une trace dans le panneau Performance de Chrome DevTools avant et après la migration. Comparez le temps passé dans le recalcul des styles, la mise en page et la peinture. Si votre configuration le permet, regardez aussi les statistiques de sélecteurs pour repérer ce qui coûte.
Et surtout : le test doit ressembler au volume de production. Une liste de 20 lignes ne révèle pas toujours ce qui se passe avec plusieurs milliers d'éléments. Reproduisez aussi l'action utilisateur réelle : sélectionner une ligne, ouvrir un panneau, ajouter un commentaire, ou redimensionner une zone.
La propriété animée compte aussi. Une transition CSS n'est pas automatiquement « plus rapide » qu'une animation JavaScript. Animer left, width ou margin peut provoquer des recalculs de mise en page à chaque image. À l'inverse, une animation sur transform ou opacity est souvent plus adaptée. Le langage ne remplace pas la propriété.
Checklist à intégrer à la pull request
Avant de remplacer un comportement JavaScript par une fonctionnalité CSS, consignez les réponses à ces six questions pendant la revue :
- Propriété : CSS ou JavaScript est-il l'unique propriétaire du comportement ?
- Portée : la règle change-t-elle l'élément, ses enfants, son parent, et ses voisins ?
- Cascade : quelles règles peuvent prendre le dessus, et lesquelles risque cette nouvelle règle ?
- Migration : l'ancien observateur, ses classes et tous les sélecteurs associés ont-ils été retirés ?
- Performance : le scénario a-t-il été mesuré avec des données réalistes, avant et après ?
- Maintenance : quelqu'un peut-il comprendre pourquoi la règle existe et jusqu'où vont ses effets ?
Une réponse incomplète ne signifie pas « abandonnez tout ». Ça veut dire : risque à tester, décision à documenter, ou partie de la migration à finir.
Conclusion
Les fonctionnalités modernes de CSS peuvent réduire la quantité de scripts, de dépendances et de contournements. Les container queries et :has() permettent souvent de rendre un composant plus autonome et son intention plus lisible. Mais rien ne garantit qu'un nouveau pouvoir rend automatiquement l'application entière plus simple.
Une migration sérieuse repose sur quatre décisions : un seul propriétaire du comportement, une portée de mise en page validée dans de vrais contextes, une cascade maîtrisée, et une mesure adaptée au volume réel. Si l'un manque, le code retiré risque de « revenir » sous forme de comportements implicites et de bugs difficiles à reproduire.
Quand une pull request efface plus de lignes qu'elle n'en ajoute, tant mieux. Mais ne vous arrêtez pas à la taille du diff : cherchez où la complexité est partie, et faites répondre l'équipe aux six questions de la checklist avant de considérer la migration terminée.