Une liste de mille commentaires se rend lentement, alors vous vous tournez vers react-window – et en échange d'un scroll fluide, vous perdez Ctrl+F, l'impression de la page et en partie la navigation du lecteur d'écran, car les éléments hors de la fenêtre cessent d'exister physiquement dans le DOM. content-visibility résout le même problème autrement : les éléments restent dans le DOM, le navigateur se contente de sauter pour eux le travail coûteux de mise en page et de peinture tant qu'ils ne sont pas proches de la zone visible – et, chose surprenante, il peut les révéler temporairement quand vous y cherchez du texte.
Dans l'article sur l'accessibilité, une modale en display:none qui restait présente dans l'arbre d'accessibilité illustrait une erreur née d'une modale construite à la main sur des divs. La vraie question est : pourquoi fallait-il la construire à la main ? J'examine ce que le <dialog> natif et l'attribut popover offrent gratuitement – top layer, piège à focus, light dismiss – et où ces deux mécanismes divergent suffisamment pour que les confondre soit le chemin le plus court vers une interface inaccessible.
La classe utilitaire .mt-4 perd face à la règle .card .card__header .card__title, alors qu'elle devrait logiquement l'emporter, puisqu'elle a été ajoutée plus tard. Ce n'est pas un hasard – c'est la spécificité qui fait exactement ce pour quoi elle a été conçue. @layer introduit un tout nouvel axe de résolution des conflits, qui agit avant la spécificité, pas avec elle – et comporte un piège si contre-intuitif qu'il trompe même une partie de la documentation sur le web.
Un champ de formulaire doit s'illuminer en rouge quand l'input à l'intérieur est invalide. Une chose simple – sauf que le CSS n'a pas su, pendant 25 ans, interroger un élément sur ce qui se passe en son sein, seulement l'inverse. J'examine comment :has() inverse cette direction, en quoi il diffère des combinateurs classiques, et où ce nouveau pouvoir coûte réellement en performance.
La même carte produit s'affiche parfaitement dans une grille et se casse dans une sidebar étroite – malgré des media queries soigneusement choisies. Le problème ne vient pas de votre code, mais de la question que pose la media query : la largeur de l'écran, pas l'espace réellement accordé au composant. J'examine comment les container queries déplacent cette question là où elle aurait dû être posée depuis le début, et ce qui se passe vraiment sous le capot quand un élément devient un « conteneur de requête ».
CSS Houdini n'est pas une seule technologie, mais un ensemble de spécifications à des degrés de maturité très différents. Découvrez quelle partie est aujourd'hui prête pour la production, comment fonctionnent réellement @property et le paint worklet, et pourquoi le reste demeure expérimental.
