Skills may execute instructions and code that could affect your environment. Marketplace scans reduce risk but do not guarantee safety. Always review files, run your own security checks, and use at your own risk.
web-typography
Security Scan Summary
Status: Safe
Source: Syntic Skills registry
Automated security scan completed with no high-risk patterns detected. Manual review is still required.
About This Skill
Use when the user mentions font pairing, typeface choice, line height, responsive typography, web font loading, type hierarchy, variable fonts, FOUT/FOIT, typographic scale, or hard-to-read text.
Downloadable SKILL.md
Download SKILL.md and place it in your Syntic skills folder. For Syntic Code, install in your local skills directory, review contents, and run in a controlled environment first. Acknowledge the risk notice above to enable the download.
---
name: web-typography
description: Use when the user mentions font pairing, typeface choice, line height, responsive typography, web font loading, type hierarchy, variable fonts, FOUT/FOIT, typographic scale, or hard-to-read text.
category: Design
version: 1.0.0
tools: []
---
# Web Typography
A practical guide to choosing, pairing, and implementing typefaces for the web. The best typography is invisible — it immerses readers in content rather than calling attention to itself.
## Core Principle
**Typography is the voice of your content.** The typeface sets tone before a single word is read — a legal site shouldn't feel playful; a children's app shouldn't feel corporate. Follow the "clear goblet" principle: typography should be like a crystal-clear wine glass, keeping focus on the wine (content), not the glass (type).
## Scoring
**Goal: 10/10.** Score = number of the 10 Quick Diagnostic rows the implementation satisfies. Bands: **9-10** = body 16px+, measure under 75ch, line-height 1.4+, clear level contrast, font payload under 200KB, fallbacks set, survives 200% zoom; **5-6** = readable but missing measure control, fallbacks, or zoom resilience; **≤3** = sub-16px body, no measure cap, FOIT, or unreadable hierarchy. Always state the current score and the specific diagnostic rows failing.
## Two Contexts for Type
All typography falls into two categories:
| Context | Purpose | Priorities |
|---------|---------|------------|
| **Type for a moment** | Headlines, buttons, navigation, logos | Personality, impact, distinctiveness |
| **Type to live with** | Body text, articles, documentation | Readability, comfort, endurance |
**Workhorse typefaces** excel at "type to live with" — versatile across sizes, weights, and contexts without drawing attention. Examples: Georgia, Source Sans, Freight Text, FF Meta.
## Typography Framework
### 1. How We Read
Understanding reading mechanics is the foundation for every typography decision. Eyes don't scan smoothly — they jump in bursts. Fighting these mechanics creates friction that drives readers away; aligning with them lets readers absorb content faster with less fatigue.
- **Saccades** — eyes jump in 7-9 character bursts; line length and letter spacing directly affect saccade efficiency
- **Fixations** — eyes pause briefly to absorb content; dense or poorly spaced text slows reading
- **Word shapes (bouma)** — experienced readers recognize word silhouettes, not individual letters
- **Legibility vs. readability** — legibility is whether characters can be distinguished (a typeface concern); readability is whether text can be comfortably read for extended periods (a typography concern: size, spacing, line length). A legible typeface can still be set unreadably
Product applications: long-form content should optimize for sustained comfort (16-18px body, 1.5-1.7 line height, 45-75 char lines); dashboard UI should optimize for rapid scanning (distinct weight hierarchy, whitespace between data groups); mobile reading should account for distance and lighting (larger body at 17-18px, higher contrast).
```css
.prose {
font-size: 1.125rem; /* 18px */
line-height: 1.6;
max-width: 65ch; /* ~45-75 characters */
}
```
### 2. Evaluating Typefaces
A typeface must pass technical, structural, and practical quality checks before it earns a place in a project. Beautiful specimens fail on screen — rendering, bandwidth, and diverse devices impose constraints print never faced.
- **Technical quality** — consistent stroke weights, even visual color across text blocks, good kerning pairs (AV, To, Ty), complete character set, multiple weights (minimum: regular, bold, italic)
- **Structural assessment** — generous x-height (better screen readability), open counters and apertures (a, e, c), distinct letterforms (Il1, O0, rn vs. m)
- **Practical needs** — test at actual use sizes on target screens, check file size, verify the license
- **Real content testing** — Lorem ipsum hides problems with character frequency, word length, and paragraph rhythm
Product applications: prioritize x-height, open counters, and even color for body text (e.g. Source Serif Pro over Didot for long reads); prioritize small-size legibility and weight range for UI/system text (Inter or SF Pro); verify glyph coverage for target languages on multilingual products (Noto Sans for broad Unicode support).
**Ethical boundary:** Always verify the web license before shipping a font — desktop/print licenses rarely cover web embedding, and unlicensed use creates real legal liability.
### 3. Choosing Typefaces
Start with purpose, not aesthetics. The content's tone, reading context, and duration should drive selection — not personal preference or trends. Purpose-driven choices feel inevitable rather than arbitrary, and survive stakeholder review because they can be justified with reasoning rather than taste.
- **Define the job first** — body text, headlines, and UI elements may each need different faces
- **Match tone to content** — a financial report needs a different voice than a bakery menu
- **Check the family** — confirm needed weights, italics, and styles exist before committing
- **Safe starting points** — body serif: Georgia, Source Serif Pro, Charter; body sans: system fonts, Source Sans Pro, Inter, IBM Plex Sans
Product applications: a content-heavy site should use a workhorse serif or sans for sustained reading (Source Serif Pro or Charter); a SaaS dashboard should use a clean sans with strong tabular figures (Inter or IBM Plex Sans); accessibility-focused products should use faces designed for maximum legibility (Atkinson Hyperlegible).
### 4. Pairing Typefaces
Successful pairings create clear contrast — faces should be obviously different, not confusingly similar. One to two typefaces maximum. Clear structural contrast (serif + sans, light + bold, humanist + geometric) gives each face a distinct role; faces that are too similar create tension without purpose.
- **Contrast types** — structure (serif + sans), weight (light + regular), era (humanist + geometric), width (condensed + normal)
- **Same designer strategy** — faces by one designer often share harmonizing DNA (FF Meta + FF Meta Serif)
- **Superfamilies** — families designed to work together eliminate guesswork (Roboto + Roboto Slab)
- **Pairing failures** — two near-identical faces, both faces competing for attention, one face overwhelming the other
Product applications: editorial sites pair serif headlines with sans body (Playfair Display + Source Sans Pro); documentation pairs monospace code with sans prose from one family (IBM Plex Mono + IBM Plex Sans); minimal brands use a single family with weight variation (Inter at varying weights and sizes).
### 5. Typographic Measurements
Three measurements — font size, line length, and line height — form the foundation of comfortable reading, and matter more than typeface choice. Optimal line length matches the saccade pattern; adequate line height prevents the eye from jumping to the wrong line on the return sweep; sufficient size makes letterforms recognizable on screen.
- **Body size** — 16px minimum; err larger (18px) for reading-heavy sites; mobile users hold phones farther than designers assume
- **Line length (measure)** — 45-75 characters ideal, 66 optimal; enforce with `ch` units or `max-width`
- **Line height** — 1.4-1.8 for body; longer lines need more; headlines need tighter (1.1-1.25)
- **Heading scale** — consistent ratio (1.2-1.5) between levels creates hierarchy without extremes
```css
.prose {
font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
line-height: 1.6;
max-width: 65ch;
}
/* Line height by context */
h1, h2 { line-height: 1.1; } /* headlines: 1.1-1.25 */
.ui-text { line-height: 1.35; } /* UI: 1.3-1.4 */
.body-text { line-height: 1.6; } /* body: 1.5-1.7 */
```
### 6. Building Type Hierarchies
Hierarchy tells readers what matters most. Create distinction through controlled variation in size, weight, and color — but don't pull all three levers at once between adjacent levels.
- **Three levers** — size, weight, color; vary one or two between adjacent levels, never all three
- **The squint test** — squinting at a page should still reveal the hierarchy
- **Consistent scale** — a modular ratio (1.2-1.5) between heading levels creates rhythm; arbitrary sizes create noise
- **Don't skip levels** — jumping H1 to H3 breaks the reader's mental model
```css
h1 { font-size: clamp(2rem, 1.5rem + 2vw, 3rem); font-weight: 700; color: #111; }
h2 { font-size: clamp(1.5rem, 1.25rem + 1vw, 2rem); font-weight: 600; color: #111; }
body { font-size: 1rem; font-weight: 400; color: #333; }
.secondary { font-size: 0.875rem; color: #666; }
```
**Ethical boundary:** Don't bury fees, disclaimers, or opt-outs in small or low-contrast type to demote what users need to see — hierarchy that hides material information weaponizes typography against the reader.
### 7. Responsive Typography and Web Font Performance
Type must adapt to screens, and web fonts must load efficiently. Fluid typography with `clamp()` eliminates breakpoint jumps; strategic font loading prevents layout shift and slow renders. A fixed font size cannot serve both a 320px phone and a 1440px desktop. Web fonts are render-blocking by default — unoptimized loading causes Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT).
- **Fluid typography** — `clamp(min, preferred, max)` scales smoothly between viewports, no media queries needed for type
- **Breakpoint adjustments** — mobile needs slightly larger body (17-18px) and a tighter heading scale; desktop can push display sizes while keeping line-length limits
- **Loading strategy** — `font-display: swap` shows fallback text immediately; preload critical fonts; subset to needed characters
- **Performance budget** — under 200KB total font payload; prefer WOFF2; a variable font can replace 4-6 static weight files
```css
h1 { font-size: clamp(2rem, 1.5rem + 2vw, 3.5rem); }
```
Product applications: content sites use fluid sizes with `clamp()`; e-commerce sites preload the hero font and lazy-load secondary weights; global products subset fonts per language to cut payload (Latin subset for English, CJK subset for Asian pages).
## Working Method
State the current diagnostic score (see Scoring) before proposing changes, name which of the 10 rows are failing, and fix body size, measure, and line-height first — those three drive most of the readability gap. Only then address hierarchy and pairing. Search the Knowledge Base for the project's existing type stack before recommending a new typeface, and use web_search to confirm a candidate font's web-license terms before recommending it.
Bundle Download
Includes SKILL.md and bundled support files where provided. Risk acknowledgement is required.
Install Targets
Syntic App
- 1. Create a dedicated folder for this skill in your local skills library.
- 2. Place SKILL.md into that folder.
- 3. Restart Syntic and invoke this skill on matching tasks.
Syntic Code (CLI)
- 1. Save SKILL.md in your local Syntic Code skills directory.
- 2. Keep related files in the same skill folder.
- 3. Run in a safe environment and validate outputs.
Source
https://github.com/wondelai/skills/blob/main/web-typography/SKILL.md
Open Source LinkRelated Skills
design-everyday-things
Use when a product feels confusing or unintuitive — apply affordances, signifiers, constraints, feedback, and...
Designdesign-sprint
Use when the user wants to prototype and test a product idea with real users fast, mentions a "design...
Designdomain-driven-design
Use when modeling software around the business domain: bounded contexts, aggregates, ubiquitous language...
Designhooked-ux
Use when designing habit-forming product loops (Trigger, Action, Variable Reward, Investment), re-engagement...