A typography token is a whole style, not a size. Text.Medium sets family, weight, size, line height and text decoration together, and there is no token for “14px” on its own. That is the useful part of the layer: you pick a role and the five properties arrive already agreeing with each other.
Type scale
Section titled “Type scale”21 alias typography tokens. Each line below is set in the token it names.
Display
3 tokensHeading
4 tokensText
14 tokensNothing in the type scale is heavier than 500
Section titled “Nothing in the type scale is heavier than 500”The package ships three weights: fontWeights.Light at 300, Regular at 400, and Medium at 500. There is no bold.
Three tokens are named as though there were. Text.LargeBold, Text.MediumBold and Text.SmallBold all resolve to fontWeights.Medium, so “bold” in PDS is the same 500 that every Display and Heading token uses. Emphasis at 14px is one weight step up from body text, and the top of the scale has no weight contrast at all — Display.Large and Text.LargeBold are the same weight 64px apart, so hierarchy there is carried by size alone.
Heading Extra Small is the only token with numbers written into it
Section titled “Heading Extra Small is the only token with numbers written into it”Twenty of the twenty-one tokens reference the size and line-height scales. Heading.ExtraSmall sets 18px and 26px as literals, and neither number is on either scale — fontSizes goes 16, 20, 24, and lineHeights has 24 and 30 but no 26.
The consequence is that it will not move. Retuning the size scale upstream shifts twenty tokens and leaves this one where it is, and the 18px step that currently sits between Text.Large and Heading.Small would end up somewhere nobody chose.
Only two type tokens carry an underline
Section titled “Only two type tokens carry an underline”Text.MediumLink and Text.SmallLink set textDecoration: underline. The other nineteen set none, no token expresses the underline on its own, and the scale therefore offers it at two sizes only — Text.Large exists, Text.LargeLink does not. Nor is the token the route most code takes: Link declares text-decoration: underline itself rather than reaching for Text.MediumLink, and the two link tokens are referenced twice each in the whole React library.
The semi-mono family ships with no token that uses it
Section titled “The semi-mono family ships with no token that uses it”fontFamilies holds three families: Primary, Monospace and SemiMonospace. All three mono type tokens — Text.Mono, Text.SmallMono and Text.ExtraSmallMono — use Monospace. SemiMonospace is referenced by no typography token at all.
It is used, though. This site sets its own monospace text in ABC Monument Grotesk Semi-Mono, and @persona/design-system exposes the family on its theme as fontFamily.semiMono. Both reach for the family directly, because there is no style token to reach for.
Two of the mono tokens are unused in the other direction: Text.SmallMono and Text.ExtraSmallMono are referenced by no component in @persona/design-system. Text.Mono is, five times — and at weight 300, which makes it one step lighter than Text.Medium at the same 14px.
Every type token has two spellings, and neither derives from the other
Section titled “Every type token has two spellings, and neither derives from the other”The Figma library spells these leaves with spaces and a slash: Text / Small Mono, Display / Large. The JavaScript export concatenates them onto the group: Typography.TextSmallMono. One leaf, Text / SmallBold, has no space in either, so it is the one token whose two spellings agree.
This page and the specimens above use a third form — the JavaScript key with the group split back off, Text.SmallMono — because it is the shortest spelling that is unambiguous in both directions. Neither of the real two is derivable from the other, so searching code for Small Mono finds nothing, and searching Figma for TextSmallMono finds nothing either.
Was this page helpful?