font-size: clamp(0.75rem, 2vw + 0.5rem, 1.5rem); — cette ligne, prise isolément, semble raisonnable. Elle promet une taille de texte qui grandit avec la largeur de l’écran, sans media query à multiplier. Le problème apparaît seulement quand on fait le calcul pour un mobile d’entrée de gamme, et qu’on découvre que le corps de texte d’un article WordPress descend à 14 pixels sur un écran de 360 pixels de large.
La typographie fluide, popularisée par la fonction CSS clamp(), est un vrai progrès par rapport aux media queries multipliées pour chaque taille de police. Mais elle déplace le risque : au lieu d’oublier une taille sur un breakpoint, on peut désormais oublier de vérifier ce que la formule produit réellement à ses extrémités. Ce billet ne traite pas du contraste des couleurs, seulement de ce piège précis de dimensionnement.
Ce qu’on voit
Sur le thème examiné, le corps de texte des articles utilise cette déclaration dans le fichier theme.json, sous forme d’un préréglage de typographie fluide :
{
"settings": {
"typography": {
"fontSizes": [
{
"slug": "medium",
"size": "clamp(0.75rem, 2vw + 0.5rem, 1.5rem)",
"name": "Moyen"
}
]
}
}
}
Sur un écran de bureau à 1280 pixels, cette formule produit une taille confortable, proche de 1,3 rem. Le problème ne saute donc pas aux yeux pendant la conception, faite sur un grand écran. C’est seulement au redimensionnement de la fenêtre du navigateur en dessous de 400 pixels, ou sur un téléphone à petit écran, que la valeur calculée s’effondre sous 0,875 rem, soit 14 pixels avec une taille de racine à 16 pixels.
Pourquoi c’est un problème
La fonction clamp(min, préférence, max) retient toujours la valeur médiane des trois arguments une fois évalués. Ici, la borne minimale vaut 0.75rem, soit 12 pixels : rien n’empêche la valeur préférée 2vw + 0.5rem de descendre jusqu’à ce plancher sur un petit écran, puisque 2vw ne vaut que 7,2 pixels à 360 pixels de large.
- En dessous de 16 pixels, un corps de texte devient nettement plus fatigant à lire sur un écran de téléphone tenu à distance de bras, en particulier pour un lecteur presbyte ou malvoyant.
- Le zoom du navigateur compense en partie, mais uniquement si l’utilisateur pense à zoomer — ce qui suppose qu’il ait déjà identifié le texte comme trop petit, une gymnastique que personne ne devrait avoir à faire.
- Le rendu incohérent d’un appareil à l’autre complique aussi les tests : un contrôleur qualité sur un écran 15 pouces ne verra jamais le problème qu’un visiteur rencontre sur son téléphone.
Quoi faire
La correction ne consiste pas à abandonner clamp(), mais à recalculer la borne minimale pour qu’elle ne descende jamais sous 16 pixels, quelle que soit la largeur du viewport :
{
"settings": {
"typography": {
"fontSizes": [
{
"slug": "medium",
"size": "clamp(1rem, 1.5vw + 0.6rem, 1.5rem)",
"name": "Moyen"
}
]
}
}
}
Avec cette nouvelle formule, la borne basse passe à 1rem, soit 16 pixels garantis même si la partie fluide venait à descendre plus bas. Le test de vérification reste simple : calculer la formule pour la largeur minimale visée (souvent 320 ou 360 pixels) et pour la largeur maximale du contenu, puis confirmer que la valeur basse ne descend jamais sous 16 pixels pour du texte courant.
Une méthode de calcul reproductible
Pour éviter de recommencer ce calcul à la main à chaque nouvelle taille de police du design system, une petite feuille de calcul ou un générateur en ligne suffit : on y renseigne la taille minimale souhaitée à la largeur de viewport minimale, la taille maximale souhaitée à la largeur maximale, et l’outil produit la formule clamp() correspondante. Le point de vigilance reste le même : vérifier la valeur minimale obtenue, pas seulement la valeur maximale qui flatte l’œil sur un grand écran.
Conseil maison : dans une revue de theme.json, demander systématiquement « à combien de pixels cette formule descend-elle à 360 pixels de large ? » évite la quasi-totalité des régressions de ce type.
En résumé
Une formule clamp() mal calibrée ne casse rien visuellement sur un poste de développement classique : elle dégrade silencieusement la lisibilité sur les écrans les plus contraints, précisément ceux où le confort de lecture compte le plus. Fixer la borne minimale à 16 pixels, puis vérifier le calcul aux deux extrémités du viewport visé, suffit à éliminer ce piège sans renoncer aux bénéfices de la typographie fluide.
