Les fonctionnalités méconnues du HTML/CSS moderne

 (lyra.horse)
14 points par GN⁺ 2025-08-30 | 3 commentaires | Partager sur WhatsApp
  • Les principales causes récentes de la dégradation des performances des sites web sont l’usage excessif de JavaScript et les scripts de suivi, alors que dans de nombreux cas, HTML/CSS suffit largement à les remplacer
  • Des fonctionnalités ajoutées récemment comme l’imbrication CSS, les couleurs relatives, les nouvelles unités de viewport (lvh, svh, dvh) permettent de résoudre simplement des tâches qui dépendaient autrefois de JS ou d’un préprocesseur
  • CSS n’est pas un simple outil de style, mais un langage puissant capable de gérer les animations, la validation des entrées, les thèmes en mode sombre, les menus accordéon et bien plus encore
  • Côté performances, CSS bénéficie de l’accélération GPU et fonctionne sur un thread séparé, ce qui le rend plus fluide et plus efficace que JS pour les animations et transitions
  • L’auteur présente CSS non seulement comme un outil pratique, mais aussi comme un moyen d’expression et un art, et encourage les développeurs web à mieux exploiter le potentiel du CSS moderne

Introduction : la complexité du web, et une nouvelle approche

  • Beaucoup de sites web souffrent de problèmes de performances et de complexité à cause de l’usage excessif des frameworks JavaScript
    • Une app React peut mettre plusieurs secondes à charger, et NextJS peut provoquer des erreurs d’hydratation
    • Le dossier node_modules peut occuper plusieurs gigaoctets
  • Même sans JavaScript, on peut implémenter des fonctionnalités puissantes avec HTML et CSS seuls
    • En dehors d’un panier e-commerce complexe ou d’un dashboard, JavaScript n’est pas forcément indispensable
  • Cet article présente les fonctionnalités récentes de CSS et invite les développeurs à explorer d’autres possibilités sans dépendre uniquement de JavaScript

Idées reçues et perception de CSS

CSS est-il vraiment difficile et inconfortable à utiliser ?

  • La perception négative de CSS vient souvent d’un manque d’apprentissage des bases
    • Beaucoup de développeurs sautent les fondamentaux de CSS pour se concentrer sur JavaScript ou TypeScript
    • CSS n’est pas un simple outil de styling, mais un langage spécialisé dans un domaine offrant de puissantes capacités
  • CSS permet de créer facilement des layouts complexes avec des outils comme flexbox
    • Exemple : display: flex et justify-content: center suffisent pour centrer simplement une div
    • Les outils de développement du navigateur proposent des widgets pour ajuster visuellement les propriétés flexbox
  • Si l’on approfondit un seul domaine (par exemple JS) en négligeant CSS, il est normal que cela paraisse difficile

La douleur d’écrire du CSS, et ce qui a changé

  • Autrefois, CSS n’était pas particulièrement confortable à utiliser, d’où l’apparition d’outils comme Sass ou Tailwind
    • Exemple : il fallait gérer de longues chaînes de sélecteurs comme .post > .buttons .like:hover
  • Récemment, des fonctionnalités d’amélioration de qualité (comme l’imbrication) ont été ajoutées, rendant le développement agréable même en CSS natif
    • L’imbrication CSS (nesting) permet de regrouper les styles liés au même endroit pour améliorer la lisibilité
      • Exemple : .post { & > .buttons { .like { &:hover { ... } } } }
      • La relation parent-enfant devient plus claire et permet d’utiliser des noms de classes plus courts et plus simples
  • Les couleurs relatives (relative colors) facilitent l’ajustement des couleurs
    • hsl(from #123456 h s calc(l + 10)) permet d’ajuster la luminosité
    • color-mix() permet de mélanger deux couleurs pour créer des couleurs dynamiques
  • La syntaxe de plage des media queries permet de définir des conditions intuitives comme (width <= 768px)
  • L’unité lh permet un styling aligné sur la hauteur de ligne
  • La propriété scrollbar-gutter résout les problèmes de déplacement de layout provoqués par la barre de défilement
  • Baseline garantit la compatibilité des fonctionnalités sur les principaux navigateurs
    • newly available signifie que la fonctionnalité fonctionne sur les navigateurs récents
    • widely available signifie qu’elle est prise en charge jusqu’aux navigateurs datant d’il y a 2,5 ans
    • Exemple : l’imbrication CSS est prise en charge sur tous les navigateurs depuis décembre 2023

Pourquoi développer uniquement avec CSS/HTML ?

  • Certains utilisateurs désactivent JavaScript par défaut (pour des raisons de sécurité, de confidentialité, etc.)
  • Proposer un site web en CSS/HTML pur augmente l’accessibilité pour ces utilisateurs
  • Du point de vue du développement comme de l’usage, n’utiliser que CSS/HTML apporte de gros avantages en vitesse, accessibilité et consommation CPU/batterie
    • Les animations CSS s’exécutent sur le thread du compositeur, ce qui réduit la charge CPU
    • JavaScript s’exécute via l’event loop, avec un léger délai possible
  • Accessibilité et facilité d’usage s’en trouvent améliorées
    • Effets de survol sur les boutons, animations de toast, validation d’entrée, etc. peuvent être implémentés simplement en CSS

Exemples concrets et principales fonctionnalités de CSS

Implémenter naturellement une animation d’entrée avec @starting-style

  • Auparavant, créer une animation d’apparition d’un élément demandait une structure complexe avec keyframes, déclencheurs JS, etc.
  • L’arrivée de @starting-style simplifie la définition de l’état initial. On peut facilement créer une animation d’état initial d’un élément (par ex. un fondu d’entrée)
    • Réglage avec transition: opacity 1s; @starting-style { opacity: 0; }
    • Cela fonctionne sans @keyframes supplémentaire ni JavaScript
  • Il suffit de déclarer l’état initial avec une transition pour que l’animation s’applique naturellement
    • Exemple : gérer en douceur les transitions d’opacité et de position d’un message toast

Configurer facilement un thème sombre/clair

  • color-scheme: light dark permet de basculer automatiquement selon la préférence de l’utilisateur
  • La fonction light-dark(#000, #FFF) permet de définir des couleurs adaptées aux modes clair et sombre
  • Les boutons radio et le sélecteur :has permettent de proposer un choix de thème à l’utilisateur
    • Le changement de thème peut se faire uniquement en CSS, sans JavaScript
    • JavaScript peut être ajouté de façon optionnelle pour sauvegarder/charger le thème

Créer une UI personnalisée avec radios/checkboxes et :has, :checked, etc.

  • Des interactions complexes comme les onglets, les accordéons ou les bascules peuvent aussi être implémentées sans JavaScript
  • Les boutons radio peuvent être personnalisés avec :checked et :has
    • Exemple : label:has(input:checked) permet de styliser le bouton sélectionné
    • On peut masquer l’élément input avec opacity: 0 tout en conservant l’accessibilité pour les lecteurs d’écran
  • L’élément details est adapté à l’implémentation de menus accordéon comme dans une FAQ
    • L’attribut name permet de contrôler un état d’ouverture unique
    • Des animations peuvent être ajoutées selon l’état [open]

Validation des entrées et reflet de l’état

  • En combinant les attributs HTML comme pattern et required avec les pseudo-classes CSS (:valid, :invalid, :user-valid, etc.), on peut fournir une validation en temps réel avec retour visuel
  • Modifier le style de l’outline/de la bordure des champs améliore l’expérience utilisateur
  • L’attribut pattern de HTML permet de valider les champs de saisie
    • Exemple : \w{3,16} autorise 3 à 16 caractères alphanumériques ou underscore
  • Les pseudo-classes CSS :valid et :invalid permettent de styliser selon la validité
    • :user-valid et :user-invalid n’appliquent le style qu’après une interaction de l’utilisateur
  • Le sélecteur :has permet de styliser d’autres éléments selon l’état d’un champ
  • Dans certains cas (par ex. conditions de saisie complexes), JS reste nécessaire, mais dans la plupart des cas, CSS/HTML suffit

Bien utiliser les unités de viewport

  • Les unités vw/vh posent des problèmes de précision sur mobile selon l’apparition ou la disparition de la barre d’adresse (navigation)
  • Il est recommandé d’utiliser les nouvelles unités de viewport comme lvh/svh/dvh (largest/smallest/dynamic viewport height)
    • lvh : pour le plein écran (par ex. un fond plein écran)
    • svh : pour des boutons, liens, etc. qui doivent toujours rester visibles
    • dvh : pour attribuer dynamiquement la taille selon les changements liés au défilement, etc.
  • Le recouvrement par le clavier peut être géré avec la propriété interactive-widget ou la VirtualKeyboard API
    • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
    • Dans les navigateurs basés sur Chromium : navigator.virtualKeyboard.overlaysContent = true

Wishlist CSS : ce qui manque encore ou qu’on aimerait voir

  • Blocs réutilisables : appliquer une autre classe dans une classe (par ex. @apply border)
  • Sélecteurs combinés avec media queries : combiner @media avec des sélecteurs de classe
  • Variable nth-child : span { --nth: nth-child(); } pour un styling dynamique
  • Sélecteur nth-letter : styliser une lettre précise (par ex. p::nth-letter(2))
  • Suppression d’unité : créer une valeur sans unité avec calc(100vw / 1px)
  • Fonction image() : prise en charge d’une couleur de remplacement et de fragments d’image
  • Balise style dans le body : prise en charge officielle par le standard pour atténuer les problèmes de FOUC

Conclusion : CSS, et la dimension artistique du web

  • CSS n’est pas un simple outil, mais un moyen d’expression créatif
  • Les outils d’IA ou les chaînes de build (linters, outils de minification) peuvent limiter la créativité
  • CSS répond à la fois aux exigences de performance, d’accessibilité et d’expression artistique
  • Cet article est écrit en HTML/CSS sans JavaScript pour un total d’environ 49 kB
    • Tous les widgets interactifs et les éléments visuels ont été implémentés à la main
    • Exemple : CSS Click Game démontre les possibilités de CSS en tant que langage de programmation

À lire aussi

3 commentaires

 
duqduqduq 2025-09-01

J’étais full-stack, mais à mesure que ma carrière a évolué, j’ai eu de moins en moins l’occasion de faire du front-end, au point de ne pratiquement pas y toucher pendant une dizaine d’années. Récemment, j’ai dû donner une formation en entreprise et, en jetant un œil au sujet pour en faire une brève introduction, j’ai été vraiment surpris de voir à quel point ça avait changé. Avec SCSS en plus, c’est encore plus agréable.

Mais le domaine du CSS reste vraiment particulier. C’est facile à apprendre, mais je pense que pour l’utiliser assez bien pour être reconnu, tout dépend du sens esthétique et de la créativité de chacun. À une époque du web où l’on accorde davantage d’importance à l’ergonomie et au design, je trouve dommage que la valeur des intégrateurs web ne soit pas davantage reconnue.
 
ahwjdekf 2025-09-01

Cette fois, comme activité de découverte des technologies de développement web, sans même les bases et en fonçant un peu tête baissée, j’ai essayé de créer un tableau d’affichage basique avec nextjs, authjs, tailwind et shadcn... et au final, la difficulté d’apprentissage la plus élevée, c’était le CSS.
 
GN⁺ 2025-08-30
Avis Hacker News

  • Je suis reconnaissant pour l’ajout récent du nesting en CSS, mais globalement je trouve vraiment que CSS est un langage étrange, et personnellement mauvais. C’est peut-être parce que je ne sais pas bien m’en servir, mais c’est tellement complexe et brouillon que j’ai l’impression de déplacer des runes incompréhensibles dans tous les sens. Le système de style et le système de layout sont mélangés, et comme l’héritage et la relation de contenance obéissent à des logiques différentes, ça rend le tout encore plus confus. Je pense que fusionner style et layout a été une erreur. J’ai aussi l’impression qu’ajouter des fonctionnalités à un système déjà fondamentalement cassé ne peut pas être la solution.

    • Moi aussi je gagne ma vie avec CSS depuis 10 ans, mais j’ai l’impression que CSS n’a pas été conçu comme un langage à part entière : il a plutôt été étendu au fil du temps. On a juste greffé de nouveaux modules sur des propriétés existantes, ce qui fait qu’ils entrent en conflit ou se comportent légèrement différemment, et ça rend le débogage difficile. On peut citer par exemple le fait que le box model et le layout flex ne fonctionnent pas pareil, ou que la propriété gap se comporte différemment entre flex et grid (lien). Une fois qu’on a construit un layout, il devient en pratique presque figé. Sans encapsulation complexe native ou basée sur JS, c’est difficile de le faire évoluer souplement. Et on finit alors avec des problèmes imprévus, comme une épaisseur de police qui change soudainement ou un menu mobile qui s’affiche aussi sur desktop.
    • Je ne suis pas d’accord. Si on voit surtout des avis négatifs sur CSS, c’est à mon avis parce que les gens ne l’ont pas vraiment appris, ou surtout n’ont pas compris la cascade. J’ai autrefois beaucoup creusé la spec CSS, et j’en suis venu à penser que c’est un langage plutôt bien conçu pour son objectif, qui est de séparer la sémantique du markup et le style.
    • Je pense qu’il est impossible de séparer style et layout. Quiconque a fait du développement UI sent bien que ces deux éléments sont intrinsèquement liés et interdépendants. Par exemple, la longueur du texte, sa taille, l’overflow, les margin, les padding s’influencent mutuellement. Si on change la bordure ou l’espacement d’un élément, on modifie aussi l’espace disponible pour son contenu. On ne peut pas les séparer complètement.
    • Le vrai problème de CSS, selon moi, c’est la cascade. Et d’ailleurs, une grande partie du développement frontend moderne consiste justement à essayer de l’empêcher. La componentisation de l’UI en est un bon exemple. Le layout est encore un autre problème, rendu plus complexe par la compatibilité. Si tous les layouts fonctionnaient par défaut uniquement avec flexbox ou grid, et qu’on ne mélangeait pas inline et non-inline dans un même conteneur, ce serait bien mieux. React Native fonctionne exactement comme ça. Dans React Native, les styles ne se propagent pas par cascade, donc c’est bien plus simple à gérer.
    • Tout cela est vrai. Mais c’est ce qu’on a aujourd’hui. Je me suis déjà demandé s’il ne serait pas possible de créer un modèle plus cohérent conceptuellement, puis de le transpiler en CSS. On pourrait peut-être même implémenter de manière mathématique un système de layout plus propre avec container queries, calc, etc. Les langages de préprocesseur actuels ne font au fond qu’ajouter d’autres fonctionnalités inabouties à des concepts déjà inaboutis dans CSS, ce qui rend les choses encore plus confuses.

  • Le pire avec CSS, c’est qu’énormément de gens ne l’apprennent même pas vraiment, l’utilisent de force pendant une journée, puis développent des opinions très tranchées.

    • Moi aussi, j’ai eu cette « journée ». Je faisais une app de podcast et je voulais créer un footer flottant qui soit (1) toujours en bas, (2) toujours visible, (3) sans masquer le contenu et (4) sans bidouille particulière. Puis j’ai découvert que c’était impossible en CSS. Vraiment un super système.
    • J’ai appris CSS il y a 20 ans. Ma conclusion, c’est qu’à cause de la cascade, CSS devrait être renommé en Crappy Style Sheets. Dès que plusieurs personnes collaborent, le phénomène du « si tu changes ça ici, quelque chose casse n’importe où ailleurs » devient la norme. Le système repose sur des règles complexes d’override, et si c’est la base, ce n’est pas bon signe. Les moyens de cibler de façon compliquée deviennent de plus en plus compliqués, jusqu’à produire du code comme .foo > .bar:nth-child(2n) ~ .baz. Et là, ça casse encore le code d’un collègue. Même pour un layout simple, ça donne mal à la tête. C’est nettement mieux aujourd’hui, certes, mais le problème vient dès l’origine de cette structure centrée sur la cascade. Les autres critiques, comme la syntaxe, sont secondaires. Si c’était pratique et facile à utiliser, la syntaxe serait acceptable, mais CSS ne l’a pas été. Créer des layouts web ne devrait pas être un métier.
    • Concernant l’idée que « beaucoup de gens utilisent CSS sans l’apprendre », exiger qu’on maîtrise plus de 20 specs différentes juste pour avoir le droit de l’utiliser, c’est excessif. Si des gens rencontrent des problèmes en utilisant un outil, il faut regarder si l’outil a un problème, pas rejeter la faute sur les personnes. Au lieu d’obliger les gens à manier une scie avec précaution, il vaut mieux ajouter des dispositifs de sécurité.

  • L’argument « certains utilisateurs ne veulent pas de JavaScript » ne me parle pas vraiment dans cet article. Je suis moi-même utilisateur d’Arch et très porté sur le scripting et le crawling, mais je n’ai pas l’impression qu’il soit particulièrement important de se concentrer sur les environnements « NoScript ». Ça me semble être une préférence d’une toute petite minorité qu’on peut globalement ignorer. Ça me rappelle un peu l’époque du « 10 % des gens utilisent IE6 ». Je pense malgré tout qu’il y a énormément d’autres raisons pour lesquelles CSS est préférable. Quoi qu’il en soit, ce n’est pas l’enjeu principal ici, mais c’est l’impression générale que me donne le propos.

    • Ce qu’on peut faire en quelques lignes de manière déclarative en CSS devient des dizaines de lignes en JS impératif, avec davantage de comportements bizarres, de problèmes de compatibilité avec les frameworks et de délai avant l’interactivité. L’environnement NoScript n’est qu’un bonus. Au fond, DSSSL me manque.
    • Dans l’article, les utilisateurs qui n’aiment pas JavaScript ne sont mentionnés qu’en passant, alors que la majeure partie du texte se concentre sur les fonctionnalités CSS elles-mêmes. La performance fait aussi partie des motivations, mais présenter les techniques CSS me semble être une approche bien plus productive.
    • J’utilise Internet au quotidien dans un environnement NoScript. Je n’autorise des exceptions que pour les sites qui ont besoin de JS. C’est plutôt bon pour les performances, la batterie et la sécurité. As-tu déjà vécu plus d’une semaine avec NoScript ? J’avais la même opinion avant d’essayer. Pour info, je suis l’auteur de ce billet de blog.
    • Je ne pense pas que la population d’utilisateurs NoScript soit vraiment significative ni qu’elle doive être ciblée. Mais même si l’auteur ne le dit pas explicitement dans ce court passage, je pense qu’écrire moins de code et s’appuyer davantage sur la plateforme du navigateur apporte une valeur énorme. Laisser le navigateur faire le plus possible, c’est un gain d’efficacité considérable.
    • Je pense que, pour l’affirmation « certains utilisateurs ne veulent pas de JavaScript », en réalité la très grande majorité des utilisateurs n’en veulent pas.

  • Je n’avais pas réalisé que le nesting était désormais un standard officiel. Jusqu’à récemment, je pensais que c’était encore au stade de proposition. CSS a beaucoup de bizarreries, mais on sent quand même une évolution vers un langage de plus en plus correct, un peu comme JavaScript. Flexbox, le sélecteur :has et le nesting ont résolu beaucoup de points de douleur qu’on traînait depuis longtemps.

  • Deux fonctionnalités CSS qui étaient sur ma wishlist existent déjà dans la spec.

    • Les variables de n-ième enfant peuvent être implémentées avec sibling-index() et sibling-count() (explication MDN)
    • Les blocs réutilisables existent dans le brouillon de spec @function et @mixin (brouillon de spec, explication CSS Tricks)
    • Les deux sont déjà implémentés dans Chrome et utilisables.

  • Je trouve la syntaxe CSS affreuse. Je pratique 10 à 15 langages, et CSS est de loin le plus difficile à lire et à comprendre. C’est plus obscur que l’assembleur x86. CSS ressemble à une entrée pré-tokenisée pour le moteur de rendu, mais ce n’est même pas vraiment du token, et c’est étrange à écrire pour un humain. On devrait s’en servir comme contre-exemple du type « il ne faut pas faire ça », comme l’ASN.1 dans les RFC.

    • Je me demande combien de ces langages sont déclaratifs ou spécialisés domaine. Comparer CSS à l’assembleur n’est pas très pertinent : CSS est déclaratif, l’assembleur est tout l’inverse. La plupart des développeurs frontend ont aussi du mal au début quand ils passent d’un langage impératif à CSS, mais ça va mieux avec l’habitude. Le vocabulaire et les concepts CSS viennent surtout du design et de l’édition, pas de l’informatique. Beaucoup de développeurs abordent CSS comme un ensemble d’instructions explicites, alors que CSS fonctionne d’une manière particulière où les propriétés s’influencent mutuellement. Une seule propriété peut parfois changer tout l’algorithme de layout (introduction aux algorithmes de layout CSS)
    • Même si on « pratique 15 langages », je pense que CSS est vraiment difficile à connaître en profondeur. Même si on utilise beaucoup de langages de programmation, il faut une quantité énorme d’expérience concrète avant de pouvoir dire qu’on les « connaît » vraiment (biais de profondeur explicative sur Wikipédia). La meilleure manière de comprendre CSS, c’est de regarder directement le rendu et de l’évaluer. C’est comme ça que je l’utilise depuis des décennies.
    • Moi aussi, j’ai l’impression que CSS est le pire des trois HTML/CSS/JS.
    • J’aimerais bien entendre plus précisément ce que tu veux dire par « CSS est une entrée pré-tokenisée ».
    • Du code comme font-size: 12px n’est pourtant pas particulièrement difficile à lire pour un humain, donc j’ai du mal à comprendre pourquoi tu le trouves si compliqué. Pour moi, c’est vraiment simple.

  • Je me demande si l’exemple d’onglets radio est correct du point de vue accessibilité. Il me semble que, selon les recommandations WAI-ARIA, les attributs aria-selected, tabindex et aria-controls doivent être mis à jour en JS quand on change d’onglet, mais je n’en suis pas sûr. L’accessibilité passe souvent au second plan, et on a parfois l’illusion que le HTML/CSS seul garantit automatiquement l’accessibilité. C’est un point à reconsidérer quand on choisit une approche.

    • D’après ce que je sais, ces onglets radio fonctionnent bien avec la navigation clavier et les lecteurs d’écran, et suivent le flux de déplacement onglet-contenu de l’exemple WAI-ARIA (exemple WAI-ARIA). Je n’ai pas de formation en accessibilité, mais j’essaie de vérifier autant que possible. J’ai aussi moi-même testé avec plusieurs outils d’accessibilité.
    • Dans le texte original, l’auteur mentionne l’accessibilité à plusieurs reprises et a même fait des efforts pour contourner des bugs de navigateur (note associée).
    • L’accessibilité de ce billet lui-même (surtout le contraste) est tellement mauvaise que, de mon point de vue de développeur web travaillant dans une association pour personnes handicapées, j’aurais du mal à le recommander comme référence.

  • On peut implémenter ce genre d’effets interactifs sans JS (page d’exemple)

      • animation de confettis qui tombent
      • notification avec fonction de fermeture
      • quand on ferme la notification, les confettis disparaissent aussi
      • les onglets fonctionnent aussi (mais dans cet exemple, un rechargement serveur est nécessaire)
      • en ajoutant du JS, l’animation devient plus fluide et plus riche

  • En tant que développeur web avec 10 ans d’expérience, je pense que ce genre d’article doit remettre en question nos certitudes. Le titre n’est pas très bon, au point que j’ai failli ne pas le lire. À noter qu’on ne peut pas faire de rendu de carte avec CSS seul.

    • Avec CSS+SVG, on peut faire du rendu de carte. Bien sûr, il faut ensuite implémenter séparément les fonctions annexes comme la navigation.

  • Le nom Vega peut peut-être prêter à préjugé, mais j’aime vraiment beaucoup ce site. Le design global est excellent, et le contenu de cette page l’est aussi. Je vais clairement partager ce lien à des gens qui font du développement web. J’aime aussi beaucoup arrupted, qui avait déjà produit des choses impressionnantes auparavant, donc ça m’a fait plaisir de revoir un domaine familier en page principale.