| name | type-foundations |
| description | Use when typographic vocabulary or first principles are needed — what an em actually is, font vs typeface, leading vs line-height, points vs pixels, how CSS units relate, what the em square means. Also use when someone is confidently using a term incorrectly, or when an explanation needs grounding before a decision is made. |
Type foundations
The vocabulary and measurement system everything else depends on. Most
typographic mistakes at the decision level trace back to a wrong model here.
1. When to invoke
- A term needs defining before a decision can be made.
- Someone conflates font/typeface, leading/line-height, or point/pixel.
- Choosing CSS units for type.
- Explaining a typographic decision to a developer or client.
Do not invoke when the decision is already scoped — go to the specific skill.
2. Required context
- The medium — print units and screen units are related but not equivalent.
- The audience's existing vocabulary, so you correct only what matters.
3. Invariant principles
Typeface vs. font. A typeface is the design (Helvetica). A font is a
specific instance of it that you use (Helvetica Bold 12pt; a .woff2 file).
Historically a font was one size of metal type. The distinction matters in
licensing and in file inventories.
Glyph vs. character. A character is the abstract unit (the letter "a"); a
glyph is a drawn form. One character may have many glyphs (small cap, oldstyle,
alternate); one glyph may represent several characters (the fi ligature).
The em square is the design space. An em is not the width of "M" — it's the
full body of the type, historically the metal block. Glyphs are drawn within it and
may fill it generously or sparsely, which is why two typefaces at the same point
size render at visibly different apparent sizes.
Point size measures the body, not the letters. Nothing in a font is guaranteed
to be exactly the point size. This is why apparent size must be judged visually.
Leading vs. line-height. Leading is historically the extra metal strip added
between lines. CSS line-height is the total line box — the font size plus
the space distributed above and below. So font-size: 16px; line-height: 24px
means 8px of added space, not 24px. Don't use the terms interchangeably when
precision matters.
Half-leading. CSS splits the difference between line-height and font size
equally above and below the text. This is why text sits with extra space above the
cap-height and below the baseline — and why text-box-trim exists.
4. CSS units for type
| Unit | Relative to | Use for |
|---|
rem | Root font size | Default for type sizes. Respects user preference, predictable |
em | The element's own font size | Spacing that must scale with local text (margins on a heading) |
px | Device pixel (CSS px) | Borders, hairlines. Avoid for type sizes — historically blocked user text scaling and remains less preference-responsive |
ch | Width of the 0 glyph | Rough measure caps only — varies per font, so unreliable for layout (Rutter) |
ex | The font's x-height | Rare; occasionally useful for optical alignment |
% | Parent | Compounding; use with care |
vw/vh | Viewport | Never alone for type — ignores user zoom. Only inside clamp() with a rem term |
| unitless | Font size, at compute time | Always for line-height — inherits proportionally |
Why unitless line-height. A unitless value is inherited as a ratio and
recomputed against each element's own font size. A px or em line-height is
computed once and inherited as a fixed length, so a larger child gets a line box
too small for it.
5. Context-dependent heuristics
- Root font size is the user's setting. The common default is 16px, but users
change it. Sizing in
rem honours that; sizing in px doesn't.
- Points for print, pixels/rem for screen. 1pt = 1/72in. CSS px is a
reference pixel, not a hardware pixel — on high-DPI screens one CSS px covers
several device pixels.
text-box-trim / text-box-edge remove the half-leading so text can be
aligned by cap-height or x-height rather than by line box — the long-standing
"why is there mystery space above my heading" fix. Chrome/Edge 133+, Safari
18.2+, not Firefox as of mid-2026; ~80% availability, not Baseline. Degrades
silently to today's behavior, so it's safe progressive enhancement.
6. Failure patterns
| Pattern | Cause | Fix |
|---|
| "Set leading to 24px" | Leading/line-height conflated | State which; prefer unitless line-height |
| Child text has a cramped line box | line-height in px or em | Unitless |
| User's larger text setting ignored | px type sizes | rem |
| Measure cap drifts when the font changes | ch treated as stable | ch varies per font; verify or use rem |
| Same pt size, different apparent size | Point size measures the body | Compare x-heights |
| Unexplained space above a heading | Half-leading | text-box-trim, or negative margin as fallback |
| "Font" and "typeface" used interchangeably in a licence discussion | Terms conflated | Be precise; licensing depends on it |
7. Evaluation procedure
- Identify which term is actually meant, and restate it precisely.
- Check every
line-height is unitless.
- Check type sizes are in
rem (or clamp() containing a rem term).
- Check no
vw-only type sizing.
- If
ch is used for measure, confirm it was verified with the shipping font.
- Confirm the root font size isn't hardcoded in a way that defeats user
preference.
8. Output format
Term clarified: <term> = <precise definition>
Units: sizes in <unit> · line-height <unitless?> · measure in <unit>
Issues: <list>
Implication: <what changes as a result>
9. Examples
Developer asks: "the designer said 16/24 — do I set line-height: 24px?"
The intent is a 1.5 ratio, so set line-height: 1.5 unitless, not 24px. Two
reasons. First, a px line-height is inherited as a fixed length: a child at 32px
would get a 24px line box, which is smaller than its own text. Second, unitless
recomputes per element, so the ratio survives every size in the scale. Also worth
naming: "16/24" is line-height, not leading — leading is the 8px added between
lines, and the distinction matters if you're ever translating a print spec.
10. Counterexamples
- ❌ "An em is the width of the capital M." — It's the full type body; the M
connection is historical coincidence.
- ❌ "Set line-height in px for precise control." — Breaks inheritance.
- ❌ "Use
px so text renders consistently." — Consistency at the cost of ignoring
the user's text-size preference.
- ❌ "
ch is the character width, so 65ch is 65 characters." — ch is the 0
glyph's advance width and varies per font; the rendered count will differ.
- ❌ "16px is the standard body size." — It's the common browser default, which
the user may change, and apparent size varies by typeface.
- ❌ "Leading and line-height are the same thing." — Related, offset by the font
size, and the difference matters when translating print specs.
11. Source citations
- Lupton, Thinking with Type 3e — typeface vs. font; anatomy and alignment;
typographic conventions and their history.
- Rutter, Web Typography — em, rem, and ch as the primary tools for adaptive web
type; the caution that
ch "varies from font to font so it's not usually
suitable for layout purposes"; "a pixel is not a pixel" and subpixel rendering.
- Stocks, Universal Principles of Typography — the em square "at the heart of it
all"; font metrics; characters vs. glyphs.
- Latin, Better Web Typography — anatomy vocabulary; practical unit use.
- Hochuli, Detail in Typography — the line and linespacing as craft terms.
- MDN —
line-height,
text-box-trim
(Chrome/Edge 133+, Safari 18.2+, not Firefox as of mid-2026).
