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.
