Ouvrez la feuille de style de n’importe quel site livré cette année. Vous y trouverez presque toujours la même chose : trois ou quatre largeurs de rupture, et sous chacune, les mêmes valeurs redéclarées. C’est le responsive de 2012, et il tient encore la majorité du web.

L’autre école existe depuis que clamp() est partout. Elle ne redéclare rien, elle interpole. La différence n’est pas une affaire de goût, c’est une différence de méthode, et elle se paie à des endroits précis.

La maquette cesse d’arriver par tranches

L’adaptatif suppose qu’on a dessiné les écrans qu’il sert. En pratique on en dessine deux ou trois, et tout le reste de l’intervalle n’a jamais été vu par personne. Un visiteur en 1100 pixels de large regarde une composition que le designer n’a pas validée : c’est la maquette 1440 comprimée de force, ou la 768 étirée jusqu’à ce que les proportions cèdent.

Le fluide inverse la charge de la preuve. On dessine les deux bornes, et ce qui vit entre elles se déduit de la même règle. Le rapport entre un titre et son texte, entre une marge et une colonne, ne dépend plus de la largeur. Ce qu’on a validé, c’est la proportion, pas la valeur.

Le temps de développement, qui se compte au dixième changement

Vingt tailles, quatre paliers : quatre-vingts déclarations à écrire, à tester, et à retoucher chaque fois que la maquette bouge d’un cran. En fluide, vingt tailles font vingt déclarations, et le nombre de paliers n’entre pas dans l’équation.

Le gain ne se voit pas le premier jour. Il se voit au dixième changement. Une échelle centralisée se corrige à la source. Une échelle dupliquée par palier se corrige quatre fois, ou trois fois et demie, et c’est la demie oubliée qui part en production.

Le pliant, l’ultra-large, et tout ce qu’on n’avait pas prévu

Un téléphone pliant récent affiche autour de 450 pixels de large replié, et près de 880 déplié. Ni l’une ni l’autre de ces largeurs ne tombe dans une case du triptyque mobile, tablette, desktop, et le passage de la première à la seconde se fait pendant que la page est à l’écran.

À l’autre bout, le dernier palier de Tailwind s’arrête à 1536 pixels. Au-delà, plus rien ne bouge : un écran de 3440 reçoit exactement la mise en page d’un écran de 1536, avec du vide autour. Le fluide n’a pas ce problème parce qu’il ne connaît aucun catalogue d’appareils. EVA CSS interpole de 320 à 1920 pixels autour d’une référence à 1440, et ce qui dépasse est borné par décision, pas par oubli.

Le zoom, que les paliers en pixels ignorent

Un point de rupture déclaré en pixels ne sait rien de la taille de police du navigateur. Un visiteur qui monte sa police par défaut n’a pas changé de largeur d’écran : le site lui sert la même mise en page avec du texte plus gros dedans, et ça déborde. C’est le défaut connu de Webflow, dont les points de rupture sont en pixels, et c’est l’argument technique que Lumos avance pour passer tout son sizing en clamp(). Tailwind a corrigé le tir en déclarant ses paliers en rem, mais un palier en rem reste un palier.

Une taille fluide se comporte autrement, et la mécanique mérite d’être regardée de près :

font-size: clamp(2rem, 1.694rem + 1.306vw, 3rem);

Le plancher, le plafond et l’origine sont en rem, donc ils suivent la police du navigateur. Seule la pente est en vw. Le texte grandit quand l’écran grandit, et il grandit aussi quand l’utilisateur en a besoin. Aucun palier ne sait faire les deux.

Ce que font déjà les sites qu’on regarde

Ce n’est pas une avant-garde. J’ai ouvert le CSS de anthropic.com : c’est un site Webflow, et son échelle de tailles est intégralement fluide. Trente-quatre variables en clamp(), vingt-deux pas d’espacement, onze tailles de texte, plus la marge du site, toutes interpolées entre 375 et 1600 pixels.

On y retrouve, nommées à l’identique, les variables de Lumos, le framework fluide de Timothy Ricks pour Webflow : --site--margin, --site--column-count, --grid-breakout. Et la feuille de style principale, 280 kilo-octets, ne contient plus que treize blocs de media queries, 8 % de son poids, dont douze sont les trois paliers hérités de Webflow.

Voilà le rapport de force que je cherche sur un projet : le sizing en continu, les media queries réservées aux vrais changements de structure. Ce site-ci en tient exactement une.

Pourquoi l’IA continue de coder en paliers

Demandez une page responsive à un modèle. Vous recevrez md:text-2xl lg:text-4xl. Ce n’est pas un avis technique, c’est un effet de corpus : quinze ans de tutoriels, de frameworks et de réponses acceptées ont installé le palier comme la façon normale d’écrire du responsive, et l’idiome documenté de Tailwind reste le préfixe de point de rupture.

Un modèle restitue la moyenne de ce qu’il a lu. Il ne proposera pas le fluide de lui-même. Il l’exécute très bien quand on le lui demande, avec la formule, les bornes et la courbe qu’on lui donne. C’est encore une décision, et je la prends.

Ce que je retiens

L’adaptatif n’est pas faux. Il est cher. Il coûte des déclarations en double, des largeurs que personne n’a dessinées, des appareils hors catalogue et un débordement au premier zoom. On le paie en maintenance, longtemps après la livraison.

Le fluide ne demande pas plus de travail, il en demande moins, à condition de poser l’échelle une fois pour toutes. C’est exactement ce que fait EVA CSS : des bornes, une courbe, une source de vérité, et plus rien à redéclarer.