Nommer les tokens typographiques (display, heading, body, caption)
Nommez les tokens typographiques d’après le rôle que joue le texte —
display, heading-lg, body-md, caption — jamais d’après leurs valeurs
(font-24) ni d’après les éléments HTML qu’ils stylisent (h2-size). Les
noms fondés sur des valeurs deviennent obsolètes dès que l’échelle est
réajustée, et les noms fondés sur des éléments couplent le style visuel au
balisage du document, deux décisions distinctes. Un nom de rôle énonce la
seule chose du token censée rester vraie : le travail que fait ce texte.
La seconde moitié de la règle compte tout autant : un token typographique est
composite. La taille, l’interligne, la graisse et l’espacement entre
lettres voyagent ensemble sous le nom de rôle — un body-md qui ne porte
qu’une taille n’est pas un style, c’est un nombre. Cet article couvre les deux
moitiés, la convention de tailles de t-shirt qui garde les ensembles de rôles
restreints, et le chemin d’export qui porte les noms vers CSS, Tailwind et
Figma. Il fait partie de notre guide de l’échelle typographique.
Pourquoi ne pas nommer les tokens d’après leurs valeurs ?
Parce que les valeurs sont la partie du système conçue pour changer. Supposons
que votre échelle génère une taille de titre de 24 px et que vous nommiez le
token font-24. Le trimestre suivant, le ratio passe de 1,25 à 1,333 et cette
marche calcule désormais 25 px. Vos deux options sont mauvaises : renommer le
token partout où il est utilisé — un changement cassant dans chaque feuille de
style, chaque composant et chaque fichier de design qui le référence — ou
conserver un token nommé font-24 dont la valeur est 25, ce qui est pire, car
le nom ment désormais activement.
Un nom de rôle survit au réajustement sans y toucher. heading-md peut passer
de 24 px à 25 px et chaque usage reste correct, car le nom n’a jamais
revendiqué une valeur — il a revendiqué un travail, et le travail n’a pas
changé. C’est le même raisonnement qui éloigne les systèmes de couleur des
noms comme blue-500 pour des emplacements sémantiques : nommez la
décision, pas la réponse du moment.
Pourquoi ne pas nommer les tokens d’après les éléments ?
h2-size semble inoffensif — jusqu’à ce que le style et le balisage doivent
diverger, ce qui, dans les produits réels, arrive constamment. Les niveaux de
titre en HTML expriment la structure du document : un h2 est « une section
un niveau sous un h1 », un fait sur lequel s’appuient les lecteurs d’écran et
les plans de document. Le rang visuel est une décision distincte. Le titre
d’une carte peut être un h3 sur le tableau de bord et un h2 sur sa propre
page tout en paraissant identique dans les deux cas ; une page juridique peut
porter six niveaux de structure mais seulement trois niveaux de différenciation
visuelle.
Les tokens nommés d’après les éléments imposent un choix entre deux modes
d’échec : choisir l’élément pour son apparence (mauvais plan de document, un
coût d’accessibilité) ou le choisir pour la structure et obtenir le mauvais
style. Les tokens nommés d’après les rôles dissolvent le conflit — n’importe
quel élément peut porter heading-md, et le plan du document reste une
décision sémantique indépendante.
Que contient réellement un token typographique ?
Un style de texte complet. Les propriétés d’un style de texte se règlent comme un tout : un titre de 28 px reçoit son interligne de 36 px *parce qu’*il fait 28 px, sa graisse de 600 parce que les titres se hiérarchisent par leur noirceur, son espacement entre lettres de −0,01em parce que l’espacement intégré des polices paraît lâche à mesure que les tailles augmentent. Appliquez la taille sans le reste et vous n’avez pas appliqué le style — vous avez appliqué un fragment et laissé les trois autres propriétés à ce que le contexte hérite par hasard.
C’est pourquoi le format de tokens DTCG
définit typography comme un type composite : un seul token dont la valeur est
le paquet entier — famille, taille, graisse, interligne, espacement entre
lettres — plutôt que cinq tokens épars qui espèrent être utilisés ensemble.
Comment fonctionne la convention taille-de-t-shirt-dans-le-rôle ?
La plupart des systèmes s’accordent sur un nom en deux parties : d’abord la
famille de rôle, ensuite une taille de t-shirt au sein du rôle —
body-sm, body-md, body-lg.
Les familles sont peu nombreuses et stables :
display au sommet, une série de tailles heading, une série de tailles
body, et les petits rôles utilitaires — caption et overline — en bas. Le
suffixe de t-shirt absorbe la croissance : quand un design a réellement besoin
d’un style de corps plus grand, body-lg apparaît sans rien renommer de ce
qui existe.
Deux conventions gardent les ensembles honnêtes. Les rôles qui n’apparaissent
qu’une fois ne reçoivent pas de suffixe — caption plutôt que caption-md —
jusqu’à ce qu’une deuxième variante existe réellement. Et display se place
au-dessus de la série des titres comme sa propre famille plutôt que comme
heading-xl, car son travail (une accroche héroïque lue d’un seul coup d’œil)
diffère de celui d’un titre (l’orientation), et ses propriétés — interligne
plus serré, espacement entre lettres plus serré — brisent le motif des titres
au lieu de le prolonger.
À quoi ressemble un ensemble de rôles complet ?
Voici un ensemble concret, généré à partir d’une base de 16 px au ratio 1,333 avec deux marches par intervalle, les interlignes alignés sur la grille de ligne de base de 8 px (la moitié de la base) et la famille de police omise par souci de concision :
{
"type": {
"display": { "$type": "typography", "$value":
{ "fontSize": "51px", "lineHeight": "56px", "fontWeight": 700, "letterSpacing": "-0.02em" } },
"heading-lg": { "$type": "typography", "$value":
{ "fontSize": "38px", "lineHeight": "48px", "fontWeight": 700, "letterSpacing": "-0.015em" } },
"heading-md": { "$type": "typography", "$value":
{ "fontSize": "28px", "lineHeight": "36px", "fontWeight": 600, "letterSpacing": "-0.01em" } },
"heading-sm": { "$type": "typography", "$value":
{ "fontSize": "21px", "lineHeight": "28px", "fontWeight": 600, "letterSpacing": "0em" } },
"body-lg": { "$type": "typography", "$value":
{ "fontSize": "18px", "lineHeight": "28px", "fontWeight": 400, "letterSpacing": "0em" } },
"body-md": { "$type": "typography", "$value":
{ "fontSize": "16px", "lineHeight": "24px", "fontWeight": 400, "letterSpacing": "0em" } },
"body-sm": { "$type": "typography", "$value":
{ "fontSize": "14px", "lineHeight": "20px", "fontWeight": 400, "letterSpacing": "0em" } },
"caption": { "$type": "typography", "$value":
{ "fontSize": "12px", "lineHeight": "16px", "fontWeight": 400, "letterSpacing": "0.02em" } },
"overline": { "$type": "typography", "$value":
{ "fontSize": "12px", "lineHeight": "16px", "fontWeight": 500, "letterSpacing": "0.08em" } }
}
}Chaque taille se situe sur l’échelle, chaque interligne est un multiple de la ligne de base de 8 px, et chaque token se lit comme un style complet — le relecteur voit d’un coup d’œil que les petites tailles gagnent en graisse et en espacement tandis que les grandes tailles perdent les deux.
C’est la forme que Scale Composer assemble à mesure que vous assignez des marches d’échelle aux rôles : ouvrez l’export de tokens de cette échelle — les niveaux sémantiques de caption à display, chacun rassemblé avec sa taille, son interligne, sa graisse et son espacement entre lettres sous son nom de rôle.
Comment les tokens de rôle voyagent-ils vers le code et les outils de design ?
Les noms de rôle sont le contrat ; les formats sont des moyens de transport. À
partir d’une seule source DTCG, le même ensemble s’exporte en propriétés
personnalisées CSS, en bloc @theme Tailwind v4, et en Variables Figma — de
sorte que le body-md qu’un designer applique dans Figma et le body-md qu’un
développeur référence dans une feuille de style sont le même token, pas deux
conventions qui riment par hasard. Ce vocabulaire partagé est le véritable
bénéfice du nommage par rôle : « mets-le en heading-sm » est une instruction
que les deux camps peuvent exécuter sans table de traduction, et un
réajustement d’échelle se propage à chaque surface en régénérant les exports
plutôt qu’en renommant quoi que ce soit.
Nommez votre propre ensemble
Le nommage est plus facile tant que les valeurs sont encore vivantes :
ouvrez le même ensemble de rôles en sortie @theme Tailwind v4,
renommez un niveau, et vérifiez l’instinct qui compte — ce nom serait-il encore
vrai si chaque valeur en pixels du fichier changeait demain ? Si oui, c’est un
rôle. Si non, c’est une valeur qui porte une étiquette avec un nom dessus.