Snippets de code CSS modernes : arrêtons d’écrire du CSS comme en 2015

• Une collection de code qui compare côte à côte les anciennes techniques de contournement en CSS et les syntaxes CSS natives modernes qui les remplacent
• S’appuie sur des standards récents comme Grid, Flexbox, les couleurs OKLCH, les container queries et scroll-timeline afin de réduire la dépendance à JavaScript
• Organisé par thèmes comme les couleurs, la mise en page, les animations, les sélecteurs, la typographie et le workflow, et présente pour chaque fonctionnalité une alternative moderne
• Les standards CSS récents permettent de réduire la dépendance à JS, Sass et aux bibliothèques externes tout en exploitant au maximum les fonctionnalités natives du navigateur

[GN⁺]

Avis sur Hacker News

• Du CSS de 2025 ? Ça donne l’impression de vouloir remettre des styles inline comme en 2005 directement dans le HTML
  On parle de Tailwind, mais au fond cela revient à ignorer la séparation entre mise en forme et présentation

  • Le plus vieux mythe du développement web, c’est la notion de « séparation des préoccupations »
  • HTML et CSS ne sont qu’une séparation de technologies
    Si HTML ne gérait vraiment que le contenu et CSS uniquement le style, il n’y aurait jamais besoin de créer une soupe de div comme .container-wrapper .container .container-inner
    Le fait qu’il faille modifier le HTML à chaque changement de layout en est bien la preuve
  • Pas besoin d’obfusquer le code, il suffit d’utiliser Tailwind
  • Je pense même que c’est préférable
    Le code lié au composant est regroupé au même endroit, donc pas besoin d’ouvrir plusieurs fichiers en permanence
  • Je trouve que c’est une bonne idée
    Le layout et le style font partie d’une UI qu’on ne peut pas dissocier
    Le HTML n’est pas du contenu, c’est du layout
    Même si on croit à la séparation des préoccupations, HTML et CSS appartiennent à la même couche de présentation
    Croire qu’on peut réellement les séparer, c’est refuser de voir la réalité

• J’ai essayé de résumer les principales améliorations récentes de CSS

  1. Sélecteurs imbriqués (nested selectors)
  2. :has(...)
  3. :is(...) — avant, il fallait recourir à des astuces du genre :not(:not(...))
  4. :where(...) — similaire à :is(...), mais avec une spécificité de sélecteur égale à 0, donc pratique avec des sélecteurs complexes
  • Je suis totalement d’accord avec le point n°1
    La plupart des LLM ne connaissent pas cette fonctionnalité
    Je recommande d’ajouter des exemples dans AGENTS.md
    Le document MDN sur le Nesting Selector est une bonne référence
    En utilisant le sélecteur &, on gagne à la fois en lisibilité et en réduction de la duplication
  • Mon préféré, c’est text-box: trim
    Après 20 ans passés à expliquer aux designers qu’il était impossible d’aligner correctement le haut des capitales, j’ai l’impression d’être enfin libéré
  • Personnellement, la fonctionnalité @layer est celle que je préfère
  • Les points 2 à 4 sont bien, mais je déteste les sélecteurs imbriqués parce qu’on ne peut pas les grep

• Certains exemples montrent que l’ancienne méthode fonctionne sur tous les navigateurs, alors que la nouvelle ne marche que sur Chrome/Edge
  Je trouve irresponsable d’inclure ce genre d’exemples, car cela renforce le monopole de Blink

  • D’accord. Ce serait bien que le filtre par défaut soit défini sur « newly available » et inclue les trois grands navigateurs (Chrome/Edge, Safari, Firefox)
  • Ce n’est pas la faute du site
    Il faudrait plutôt pointer du doigt le manque de conformité de Mozilla aux standards

• Il faut arrêter de fixer des éléments sur les bords de l’écran
  Certains sites ont des éléments statiques qui occupent plus de la moitié de l’écran
  Il est plus naturel de laisser le contenu défiler

• Ironiquement, le site en question est bloqué en mode sombre et n’utilise pas prefers-color-scheme

• On se dit « super, des exemples CSS créatifs ! », puis on voit que la compatibilité navigateur est autour de 40 à 50 %, ce qui impose des limites très concrètes

  • Autrefois, ce manque de support était un gros problème, mais la situation s’est beaucoup améliorée aujourd’hui
    C’est en grande partie grâce à l’influence excessive de Chromium, mais le résultat reste positif
    Voir Interop 2025
  • Si on change le filtre des exemples pour « widely available », le taux de compatibilité devient bien meilleur
  • Ce n’est qu’une question de temps
    Les éditeurs de navigateurs ajoutent déjà certaines fonctionnalités en amont pour viser une prise en charge large plus tard

• C’est déroutant de voir des exemples marqués comme non pris en charge par Firefox alors qu’ils fonctionnent très bien dans la démo réelle
  Je me demande s’il y a un polyfill appliqué

  • Il s’agit du libellé « Limited availability »
    Le pourcentage en vert en bas à gauche indique la part des utilisateurs de navigateurs qui prennent en charge cette fonctionnalité
    C’est souvent inférieur à la moitié
    Au final, on est moins sur du « modern CSS » que sur du CSS du dernier Chrome
  • L’étiquetage du support des fonctionnalités est complètement bancal
    Par exemple, sibling-index() ne fonctionne toujours pas dans Firefox, alors qu’il est indiqué comme « widely available »

• En ce moment, je ne sais plus s’il faut utiliser Tailwind, CSS-in-JS, Sass/SCSS ou du CSS vanilla

  • Il n’y a pas de bonne réponse
    Il faut utiliser ce qui convient à l’équipe
    Si Tailwind convient, prends Tailwind ; pour un projet perso, du CSS inline ; si Sass t’est familier, continue comme ça ;
    et si tu veux tout miser sur le CSS moderne, c’est aussi un très bon choix

• Ça fait tellement longtemps que je fais du développement web que même parmi les exemples qualifiés « d’ancienne méthode », il y a encore beaucoup de fonctionnalités que je découvre pour la première fois

• Je découvre aussi la fonctionnalité d’ajustement de luminosité des couleurs
  Avant, je faisais ça avec Sass et Compass, mais la maintenance de la toolchain était pénible
  Maintenant que c’est pris en charge directement par CSS, c’est bien plus pratique