La typographie fluide avec Tailwind

Les tailles de texte par défaut de Tailwind sont des valeurs rem fixes — text-xl vaut 1.25rem à chaque largeur de fenêtre — et la typographie fluide n’est pas intégrée. Il existe trois façons de l’ajouter : écrire des expressions clamp() dans le bloc @theme de la v4, poser un seul clamp sur la taille de police de la racine pour que chaque utilitaire fondé sur le rem glisse, ou recourir à un plugin communautaire. Les deux premières n’exigent aucune dépendance, et la configuration CSS-first de la v4 a rendu la première nettement plus naturelle qu’auparavant.

Cet article calcule les deux voies sans plugin avec de vrais chiffres. L’arithmétique qui produit ces chiffres — pente, ordonnée à l’origine, bornes — est couverte dans notre guide de la typographie fluide ; la question ici est de savoir où vivent les chiffres dans un projet Tailwind.

Pourquoi la typographie fluide n’est-elle pas intégrée à Tailwind ?

L’échelle typographique de Tailwind est un ensemble de tokens nommés et statiques : text-sm vaut 0.875rem, text-base vaut 1rem, text-xl vaut 1.25rem, text-2xl vaut 1.5rem. Le rôle du framework est de nommer les tailles, pas de décider comment elles réagissent à la fenêtre — la réactivité s’exprime par des variantes comme md:text-2xl, ce qui correspond au modèle des points de rupture : des tailles qui sautent à des largeurs choisies. Si vous voulez plutôt des tailles qui glissent entre les largeurs, c’est vous qui fournissez le glissement.

Le tournant de la v4, c’est ce qui rend ce glissement peu coûteux à fournir. La configuration a migré dans le CSS : un token est déclaré dans un bloc @theme, devient une propriété personnalisée CSS, et l’utilitaire correspondant la lit — déclarez --text-xl et text-xl utilise votre valeur. Comme une propriété personnalisée peut contenir n’importe quelle expression de longueur CSS, elle peut contenir un clamp(). La typographie fluide en v4 est donc du CSS ordinaire dans un bloc ordinaire ; en v3, la même manœuvre supposait de modifier les entrées fontSize dans tailwind.config.js et de faire passer des chaînes clamp par la configuration JavaScript.

Comment écrire des tailles de texte fluides dans @theme ?

Redéfinissez les tokens de texte. Voici trois tailles dans la forme fixe que Tailwind livre par défaut :

@theme {
  --text-base: 1rem;     /* 16px à chaque largeur */
  --text-xl: 1.25rem;    /* 20px à chaque largeur */
  --text-2xl: 1.5rem;    /* 24px à chaque largeur */
}

Et les trois mêmes rendues fluides — chacune croît jusqu’à 1,125× sa taille sur des fenêtres de 360→1280px :

@theme {
  --text-base: clamp(1rem, 0.9511rem + 0.2174vw, 1.125rem);      /* 16 → 18px */
  --text-xl: clamp(1.25rem, 1.1889rem + 0.2717vw, 1.4063rem);    /* 20 → 22.5px */
  --text-2xl: clamp(1.5rem, 1.4266rem + 0.3261vw, 1.6875rem);    /* 24 → 27px */
}

Vérifiez --text-2xl aux deux extrémités : sur une fenêtre de 360px, 0.3261vw vaut ≈1.17px, et 22.83 + 1.17 ≈ 24px ; à 1280px il vaut ≈4.17px, et 22.83 + 4.17 ≈ 27px. Écrire text-2xl dans le balisage rend désormais 24px sur un téléphone étroit, 27px sur un grand écran de bureau, et la valeur intermédiaire partout entre les deux — sans variantes, sans media queries.

Deux détails méritent l’attention. Les pentes diffèrent — 0.2174vw, 0.2717vw, 0.3261vw — mais chacune est proportionnelle à la taille de son token, car chaque token croît du même 12,5 %. C’est cette proportion partagée qui maintient la hiérarchie constante tout au long du glissement ; trois clamp calculés indépendamment, chacun avec une pente arbitraire, laisseraient les niveaux s’écarter à mesure que la fenêtre change. Et chaque token de texte possède un token d’interligne associé (--text-xl--line-height), qui conserve sa valeur par défaut tant que vous ne le redéfinissez pas — l’interligne mérite sa propre décision dès que les tailles commencent à bouger.

Calculer des clamp proportionnels pour toute une échelle à la main est mécanique, ce qui est précisément ce qui le rend générable : l’export Tailwind v4 de Scale Composer en mode fluide écrit ce bloc pour vous. Réglez le glissement de base (16→18 sur 360→1280) et le clamp de chaque niveau typographique se déduit de cette unique pente — ouvrez l’export Tailwind en mode fluide et basculez l’interrupteur fixe/fluide pour voir les valeurs @theme passer du rem ordinaire aux expressions clamp() ci-dessus.

Un seul clamp sur la racine peut-il rendre chaque utilitaire fluide ?

La seconde voie ne touche pas du tout à @theme :

html {
  font-size: clamp(1rem, 0.9511rem + 0.2174vw, 1.125rem); /* ≈16px @360 → ≈18px @1280 */
}

(Gardez les bornes en rem : sur l’élément racine, le rem se résout par rapport à la préférence de taille de police du navigateur du lecteur, donc cette forme respecte ce réglage — un clamp exprimé en px l’écraserait.)

Les tailles de texte par défaut de Tailwind sont fondées sur le rem, et le rem se résout par rapport à la racine. Avec la racine qui glisse de 16px à 18px, text-xl rend 20px du côté étroit et 22.5px du côté large sans qu’un seul token change — le thème par défaut, intact, est déjà prêt pour le fluide. Deux lignes, et chaque utilitaire qui parle rem glisse.

Ce « chaque » a deux tranchants. Les utilitaires d’espacement sont eux aussi fondés sur le rem : p-4 vaut 1rem, ce qui rend désormais 16px → 18px sur le même glissement. Pour un système où l’espace doit croître avec le texte — ce qui maintient constantes les proportions texte/espace — c’est exactement ce que vous voulez. Mais c’est une décision globale : le glissement atteint tout, et exclure un seul composant suppose d’écrire ses tailles en px, en sortant du système de tokens pour cet élément. La voie @theme est par token ; la voie racine, c’est tout ou rien.

Qu’apportent les plugins de typographie fluide ?

Une catégorie de plugins communautaires génère des clamp par taille à partir d’une configuration : vous déclarez des paires min/max, ou une échelle et une plage de fenêtre, et le plugin émet des utilitaires fluides — certains ajoutent des variantes comme le dimensionnement fondé sur les container queries. Ils automatisent le même calcul que cet article a fait à la main, et ils précèdent la v4 ; une partie de leur valeur historique tenait à faire en JavaScript ce que @theme accepte désormais comme du CSS ordinaire. Si vos besoins correspondent à l’une des deux voies ci-dessus, la v4 a rendu la dépendance facultative ; si vous voulez des plages par taille qui ne partagent pas une même proportion, un plugin peut assurer cette comptabilité — à mettre en balance avec les habituelles questions de maintenance et de compatibilité que soulève toute dépendance.

Quelle voie pour quel projet ?

• Le clamp racine quand tout le système — typographie et espacement — doit bouger d’un seul tenant. Le moins de code, une seule pente à vérifier, et le calcul d’accessibilité et de zoom se vérifie une seule fois, à la racine.
• Les clamp @theme quand différents niveaux ont besoin de plages différentes — une taille d’affichage qui croît plus vite que le texte courant, ou un projet où l’espacement doit rester fixe pendant que la typographie glisse. Plus de nombres, plus de contrôle.
• Un plugin quand les plages par taille se multiplient au-delà de ce que vous voulez maintenir à la main.

Les voies se combinent aussi : plusieurs configurations de production posent un clamp sur la racine pour le glissement à l’échelle du système et ajoutent un ou deux clamp @theme pour les tailles d’affichage qui réclament une montée plus raide.

Générez le bloc à partir de votre propre échelle

Le chemin le plus rapide vers un bloc @theme fluide n’est pas de le calculer mais de le lire : ouvrez l’export avec les paramètres fluides modifiables, réglez vos propres tailles de base et votre plage de fenêtre, et regardez chaque clamp du bloc se recalculer à partir des quatre nombres. Collez le résultat dans votre feuille de style et les utilitaires que vous écrivez déjà — text-xl, text-2xl — se mettent à glisser.