Dans l'article sur les micro-interactions, j'écrivais que transform et opacity s'animent sur le thread de composition, donc même une page lourde ne devrait pas saccader l'animation d'un bouton. C'est toujours vrai – avec une réserve que cet article-là passait sous silence : si le thread principal est bloqué par une longue tâche JS, l'animation risque de ne jamais avoir la chance de démarrer, car le handler de clic lui-même attend dans la file. L'INP est la métrique qui mesure exactement cet écart – et scheduler.yield() est l'un des rares moyens de réellement le combler.
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.
Le bouton « J'aime » réagit instantanément, le cœur se remplit, le compteur augmente – avant même que le serveur ait répondu. Ce n'est pas l'illusion de rapidité de l'article sur les micro-interactions, c'est quelque chose qui va plus loin : l'interface affiche un état qui n'existe pas encore, en supposant qu'il existera bientôt. J'examine comment construire cela en toute sécurité – avec un vrai retour en arrière quand l'hypothèse ne se vérifie pas – et pourquoi un setState manuel plus un catch est une version dégradée de ce qu'offre useOptimistic.
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.
« use server » ressemble à du sucre syntaxique pour un fetch vers une API route – et c'est précisément pour cela que la plupart des implémentations le traitent comme un simple appel de fonction. C'est une erreur aux conséquences concrètes : chaque fonction marquée « use server » devient un point d'entrée public sur le réseau, et un formulaire construit sur ce mécanisme fonctionne même avant que le JavaScript ait eu le temps de se charger. J'examine ce qui se passe vraiment derrière cette directive, et où se cachent les pièges qu'on ne voit pas au premier coup d'œil dans la documentation.
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 ».
Un HTML correct n'est qu'un point de départ. Découvrez comment fonctionne vraiment l'arbre d'accessibilité, pourquoi ARIA fait plus de mal que de bien plus souvent qu'on ne le croit, et construisons ensemble un vrai accordéon, une live region et la gestion du focus dans Next.js.
Deux boutiques, le même produit, le même temps de réponse serveur – et pourtant l'une semble plus rapide et plus digne de confiance que l'autre. La différence tient aux micro-interactions : quelques centaines de millisecondes d'animation qui décident si l'utilisateur croit ce qu'il voit à l'écran. Je décortique le sujet depuis les fondamentaux – le modèle déclencheur/feedback, ce qui se passe réellement dans le moteur de rendu du navigateur, et prefers-reduced-motion.
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.
