Typography Systems

Introduction

Typography systems codify type scale, line height, font weight, letter-spacing, and responsive fluid rules as tokens and utility classes — ensuring readable hierarchy across products. Staff engineers pair typography tokens with performance strategy: variable fonts, subset woff2, font-display: swap, and size-adjust fallbacks to minimize CLS.

Reference systems: Material Type Scale, Carbon type styles, Atlassian typography tokens, Polaris font tokens.

Business problem

Business pressure: Inconsistent heading sizes across admin and marketing hurt brand trust. Typography system reduces 47 ad-hoc font-size declarations to 8 semantic roles — display, heading, body, caption.

• Readability: Line length and line-height tuned for WCAG and dyslexia-friendly defaults.
• Performance: Controlled font loading strategy per role.
• i18n: Scale accommodates CJK line-height adjustments.

Why this feature exists

Platform history: Modular scales (1.25, 1.333) from print design adapted to web — Material Roboto scale, Bootstrap $font-size-base derivatives.

• Problem solved: Arbitrary px font sizes in every PR.
• Modern role: Fluid type with clamp() + token-defined min/max.

Browser rendering perspective

Rendering impact: Web font load triggers FOIT/FOUT — typography system mandates metrics for fallback with size-adjust. Large display text affects LCP when hero is textual.

• CLS: Reserve line-height space before font swap.

Internal browser workflow

Flow: Token defines role → utility/class applies font-size, line-height, weight → responsive clamp at breakpoints or fluid globally.

Feature deep dive

Type roles:

:root {
  --font-family-sans: 'Inter', system-ui, sans-serif;
  --font-size-body: 1rem;
  --line-height-body: 1.5;
  --font-size-heading-2: clamp(1.5rem, 2vw + 1rem, 2rem);
  --line-height-heading: 1.25;
}
.text-body { font-size: var(--font-size-body); line-height: var(--line-height-body); }
.text-heading-2 { font-size: var(--font-size-heading-2); line-height: var(--line-height-heading); font-weight: 600; }

Syntax

Carbon: productive vs expressive type sets. Material: display, headline, title, body, label roles.

Examples

Font loading:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-subset.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%;
  ascent-override: 90%;
}

Real-world use

Carbon type tokens (@carbon/type). Atlassian Red Hat Text scale. Polaris Inter-based admin typography. Material 3 type scale with variable font Roboto Flex.

Real production example

Pattern: Only 8 type classes in product code; stylelint bans raw font-size except in token file.

Enterprise use case

Enterprise: DS docs show role matrix — when to use heading-3 vs title. Carbon separates productive (data UI) from expressive (marketing).

Accessibility considerations

A11y: Minimum 16px body on mobile; 1.5 line-height body text; user zoom to 200% without loss — avoid fixed px containers.

• Contrast: Large text 3:1 minimum — display roles still need token pairs.

Performance considerations

Performance: Subset fonts per script; preload only display font if LCP is hero headline; variable font one file vs many weights.

SEO considerations

SEO: Readable typography improves engagement signals; heading hierarchy in HTML not just visual size — h1-h6 match semantic roles.

Scalability considerations

Scale: i18n locale files adjust line-height tokens for ja, ar without forked components.

Common production issues

Failures: Marketing imports display font globally — admin tables break metrics alignment.

Debugging guide

Debug: Rendering → font fallback; Performance → font load waterfall.

Best practices

• Semantic type roles, not sizes in component CSS.
• font-display: swap + metric overrides.
• Match HTML heading level to visual role.

Anti-patterns

• text-sm on h1 for SEO styling.
• 12px body text in data tables.

Trade-offs

• Modular scale: harmonious; may not fit all brand guides.
• Fluid type: responsive; harder design QA at all widths.

Architecture review questions

• Type role count — too many or too few?
• Font loading budget per route tier?

Interview questions

Hands-on exercise

Exercise: Define 6 type tokens; implement fluid h1 with clamp; measure CLS with/without size-adjust.

Staff engineer notes

• Typography system = tokens + loading strategy + HTML semantics — not a font-size table in PDF.

Common pitfalls

• Too many roles — teams pick nearest anyway.

Try it yourself

Edit the CSS panel — the preview updates live. Use DevTools Performance and Accessibility panels to validate.

Summary

Typography systems encode readable hierarchy via tokens and loading strategy — aligned with Material, Carbon, Atlassian, and Polaris reference implementations.

Key takeaways

• Type roles as tokens — scale, line-height, weight.
• Font loading is part of typography system.