Pendant des années, des dizaines de comportements d'interface ont exigé du JavaScript : détecter l'état d'un champ pour styler son conteneur, adapter un composant à la largeur de son parent, positionner un tooltip, animer au défilement. En 2026, une grande partie de ce code est devenue inutile. Le CSS moderne fait nativement ce qui nécessitait hier des bibliothèques entières.
L'enjeu n'est pas cosmétique. Chaque comportement déplacé du JavaScript vers le CSS allège le bundle envoyé au navigateur, améliore les performances, réduit la surface de bugs et simplifie la maintenance. Pour un dirigeant technique, c'est moins de code à maintenir, des pages plus rapides et une meilleure expérience utilisateur — donc un impact direct sur la conversion et le référencement.
Cet article présente sept fonctionnalités CSS désormais largement disponibles (Baseline 2026) qui remplacent concrètement du JavaScript : :has(), les container queries, @scope, l'anchor positioning, les animations au scroll, le masonry natif et d'autres. L'objectif : savoir quoi supprimer de vos pages dès maintenant.
Ce que signifie Baseline en 2026
Baseline est un référentiel qui indique quand une fonctionnalité web est disponible de façon fiable dans tous les principaux navigateurs. Une feature « Baseline » fonctionne sur Chrome, Firefox et Safari, ce qui signifie que vous pouvez l'utiliser en production sans vous soucier d'incompatibilités majeures.
En 2026, ce statut est devenu un outil de décision concret pour trois raisons :
- Un signal de feu vert clair — plutôt que de vérifier manuellement le support navigateur par navigateur, vous savez d'un coup d'œil si une feature est sûre à utiliser.
- Visible dans les outils — Baseline est désormais affiché directement dans les DevTools des navigateurs, ce qui le rend accessible au quotidien pour les développeurs.
- Une vague de stabilisation — plusieurs fonctionnalités CSS majeures ont atteint Baseline en 2026, par exemple @scope (Firefox 146 a rejoint Chrome et Safari) et les animations pilotées par le scroll, disponibles sur tous les navigateurs.
Le résultat concret : des techniques qu'on réservait aux démos peuvent maintenant entrer en production sans polyfill ni fallback complexe. Encore faut-il savoir lesquelles apportent le meilleur retour. C'est l'objet des sections suivantes.
1. :has() : le sélecteur parent
Le sélecteur :has() permet de styler un élément en fonction de ce qu'il contient — ce qui était strictement impossible en CSS pur et imposait du JavaScript. C'est probablement la fonctionnalité qui supprime le plus de code dans des projets réels.
Concrètement, :has() remplace du JavaScript dans des cas très fréquents :
- Formulaires — styler un conteneur de champ quand l'input à l'intérieur est invalide, vide ou en erreur, sans écouteur d'événement.
- Cartes et listes — adapter l'apparence d'une carte selon qu'elle contient une image, un badge ou un certain type de contenu.
- Navigation et états — modifier un parent quand un enfant est actif, sélectionné ou survolé.
- Mises en page conditionnelles — changer une grille selon le nombre ou le type d'éléments présents.
Avant :has(), chacun de ces cas nécessitait d'attacher des écouteurs, de manipuler des classes et de gérer le nettoyage. Désormais, une règle CSS suffit. Le bénéfice est double : moins de JavaScript chargé et exécuté, et un comportement géré par le moteur de rendu, donc plus rapide et plus fiable.
2. Container queries : la mise en page par composant
Les container queries permettent à un composant d'adapter sa mise en page en fonction de la largeur de son conteneur, et non de celle de la fenêtre. C'est la pièce manquante du responsive design : un composant vraiment réutilisable doit s'adapter à l'espace qu'on lui donne, peu importe où on le place.
Avant les container queries, on contournait le problème avec du JavaScript : mesurer la taille d'un conteneur, écouter les redimensionnements, appliquer des classes. Cela impliquait souvent un ResizeObserver et une logique fragile. Les container queries rendent tout cela natif.
Les cas d'usage typiques :
- Composants réutilisables — une carte produit qui passe en colonne dans une barre latérale étroite et en ligne dans une zone large, automatiquement.
- Dashboards et widgets — des modules qui s'adaptent à la taille de leur emplacement dans une grille configurable.
- Design systems — des composants réellement portables, qui se comportent correctement quel que soit le contexte d'intégration.
Pour les équipes qui construisent un design system, c'est un changement majeur : il devient possible de livrer des composants autonomes et robustes. Nous nous appuyons sur ces mécanismes dans nos missions d'UX/UI d'application pour produire des interfaces vraiment modulaires.
3. @scope : le style encapsulé sans JavaScript
La règle @scope permet de limiter des styles CSS à une portion précise du DOM, sans avoir recours à des conventions de nommage complexes ni à des solutions JavaScript de CSS-in-JS. En 2026, @scope a atteint Baseline : Firefox 146 a rejoint Chrome et Safari, ce qui la rend utilisable en production.
Le problème historique du CSS est sa portée globale : un style écrit pour un composant peut fuiter et affecter d'autres parties de la page. Les équipes ont résolu ce problème avec des conventions (BEM), des modules CSS, ou des solutions JavaScript qui génèrent des classes uniques au runtime — au prix de complexité et parfois de performance.
Ce que @scope apporte :
- Encapsulation native — des styles qui ne s'appliquent qu'à l'intérieur d'une zone définie, sans risque de fuite.
- Moins de dépendances — on peut se passer de certaines solutions de CSS-in-JS qui ajoutent du JavaScript et de la complexité de build.
- Proximité du style et du composant — la portée se déclare au plus près de la structure, ce qui améliore la lisibilité et la maintenance.
Pour les équipes, c'est une simplification de l'architecture front-end : moins d'outillage, moins de runtime, des styles plus prévisibles.
4. Anchor positioning : tooltips et menus sans librairie
L'anchor positioning permet de positionner un élément (tooltip, menu déroulant, popover) par rapport à un autre, directement en CSS, en gérant les débordements d'écran. C'est exactement le travail qu'effectuaient jusqu'ici des bibliothèques JavaScript dédiées au positionnement flottant.
Positionner un tooltip correctement est étonnamment difficile : il faut calculer la position de l'élément ancre, gérer le cas où le tooltip dépasse du bord de l'écran, le repositionner, et recommencer à chaque scroll ou redimensionnement. Ce calcul, fait en JavaScript, est coûteux et source de bugs.
Avec l'anchor positioning, ces comportements deviennent déclaratifs :
- Tooltips et infobulles — positionnés automatiquement par rapport à leur cible, avec repli quand l'espace manque.
- Menus et popovers — alignés sur le bouton qui les déclenche, sans calcul manuel.
- Suggestions et autocomplétion — listes ancrées sous un champ, qui restent dans la fenêtre visible.
Le gain est notable : on supprime une dépendance entière et le code de calcul associé, tout en obtenant un comportement plus fluide géré par le navigateur. Pour des interfaces riches en interactions, c'est un allègement substantiel du JavaScript.
5 à 7. Animations au scroll, masonry et plus
Trois autres fonctionnalités Baseline 2026 remplacent du JavaScript fréquemment utilisé : les animations pilotées par le scroll, la mise en page masonry native et la combinaison container queries plus :has() pour des interfaces réactives.
- 5. Animations pilotées par le scroll — désormais Baseline sur tous les navigateurs, elles lient une animation à la position de défilement (barre de progression de lecture, apparition d'éléments, parallaxe légère) sans aucun écouteur de scroll en JavaScript. Le gain de performance est réel, car ces animations sont gérées par le compositeur du navigateur. Nous y consacrons un article dédié sur les animations scroll-driven en CSS pur.
- 6. Masonry natif — la mise en page en colonnes décalées (style Pinterest) a longtemps imposé des bibliothèques JavaScript pour calculer les positions. En 2026, la direction technique est tranchée autour de display: grid-lanes : Safari l'a déjà livré, Chrome et Firefox sont en cours. À terme, fini les calculs de layout en JavaScript pour ce cas.
- 7. Container queries combinées à :has() — en associant ces deux features, on construit des composants qui réagissent à la fois à leur taille et à leur contenu, couvrant une large part des comportements qu'on codait jusqu'ici à la main.
L'effet cumulé de ces sept fonctionnalités est considérable : sur une interface typique, une part importante du JavaScript d'interface devient supprimable, au profit de pages plus légères et plus rapides.
Comment intégrer ces features sans risque
La bonne stratégie est d'introduire ces fonctionnalités progressivement, en commençant par celles qui sont pleinement Baseline et qui suppriment le plus de JavaScript dans votre code existant. On ne réécrit pas tout d'un coup : on remplace là où le bénéfice est le plus clair.
Un plan en quatre étapes :
- Identifiez le JavaScript d'interface remplaçable — listez les comportements gérés en JS qui pourraient passer en CSS : styles conditionnels, positionnement de tooltips, animations au scroll, layouts adaptatifs.
- Commencez par :has() et les container queries — ce sont les deux features au meilleur rapport bénéfice/effort, applicables immédiatement dans la plupart des projets.
- Vérifiez le statut Baseline dans les DevTools — pour chaque feature envisagée, confirmez sa disponibilité, en gardant à l'esprit que certaines (comme le masonry natif) sont encore en cours de généralisation.
- Mesurez l'impact — comparez le poids du JavaScript et les indicateurs de performance avant et après, pour objectiver le gain.
Cette démarche réduit le bundle, améliore les performances perçues et allège la maintenance, le tout sans réécriture risquée. Si vous voulez auditer votre front-end et identifier ce qui peut passer en CSS natif, parlons-en.
FAQ — CSS Baseline 2026 : 7 fonctionnalités qui remplacent du JavaScript
Qu'est-ce que CSS Baseline et pourquoi est-ce important en 2026 ?
Baseline est un référentiel qui indique quand une fonctionnalité web est disponible de façon fiable sur Chrome, Firefox et Safari. En 2026, plusieurs features CSS majeures ont atteint ce statut, ce qui permet de les utiliser en production sans polyfill. Baseline est désormais affiché directement dans les DevTools, ce qui en fait un outil de décision concret au quotidien.
Le CSS peut-il vraiment remplacer du JavaScript ?
Oui, pour une part importante du JavaScript d'interface. Des fonctionnalités comme :has(), les container queries, l'anchor positioning et les animations au scroll gèrent nativement des comportements qui nécessitaient hier des écouteurs d'événements ou des bibliothèques. Le JavaScript reste indispensable pour la logique applicative, mais beaucoup de code purement visuel devient supprimable, ce qui allège le bundle.
Quelle fonctionnalité CSS apporte le plus de bénéfice immédiat ?
Le sélecteur :has() et les container queries offrent généralement le meilleur rapport bénéfice/effort. :has() permet de styler un parent selon son contenu, ce qui supprime beaucoup de code dans les formulaires et les listes. Les container queries rendent les composants réellement réutilisables en les adaptant à la largeur de leur conteneur. Les deux sont Baseline et applicables immédiatement.
Le masonry natif en CSS est-il utilisable en production ?
Partiellement en 2026. La direction technique a été tranchée autour de display: grid-lanes : Safari l'a déjà livré, tandis que Chrome et Firefox sont en cours d'implémentation. Tant que la généralisation n'est pas complète, prévoyez un repli pour les navigateurs qui ne le supportent pas encore, en vérifiant son statut Baseline dans les DevTools avant de l'adopter largement.
Comment migrer mon front-end vers ces fonctionnalités CSS ?
Procédez progressivement. Identifiez d'abord le JavaScript d'interface remplaçable (styles conditionnels, tooltips, animations au scroll, layouts adaptatifs), commencez par :has() et les container queries qui sont pleinement Baseline, vérifiez le statut de chaque feature dans les DevTools, puis mesurez l'impact sur le poids du JavaScript et la performance avant de généraliser.