Mmcp.market

web-typography skill

by wondelai·wondelai/skills·2.3k stars·MIT

Select, pair, and implement typefaces for web projects. Use when the user mentions "font pairing", "which typeface", "line height", "responsive typography", "web font loading", "type hierarchy", "variable fonts", "FOUT/FOIT", "typographic scale", or "the text is hard to read". Also trigger when choosing between system fonts and web fonts, optimizing font-loading performance, or designing readable long-form content. Covers readability evaluation, CSS implementation, and performance optimization. For overall UI design systems, see refactoring-ui. For dramatic typographic experiences, see top-design.

A100/100content scan

Is the web-typography skill safe?

Clean: nothing in its files matched our rules. We read 6 files in the folder on 2026-09-28.

No findings.

Install the web-typography skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/ux-design/skills/web-typography ~/.claude/skills/web-typography
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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 you choose 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:

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

Core concept: Understanding reading mechanics is the foundation for every typography decision. Eyes don't scan smoothly — they jump in bursts.

Why it works: Fighting these mechanics creates friction that drives readers away; aligning with them lets readers absorb content faster with less fatigue.

Key insights:

  • 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:

Copy patterns:

.prose {
  font-size: 1.125rem;     /* 18px */
  line-height: 1.6;
  max-width: 65ch;          /* ~45-75 characters */
}

See: references/typeface-anatomy.md when you need to name letterform parts (x-height, counter, aperture) or place a face in a classification system to justify a choice.

2. Evaluating Typefaces

Core concept: A typeface must pass technical, structural, and practical quality checks before it earns a place in a project. Beautiful specimens fail on screen.

Why it works: Screen rendering, variable bandwidth, and diverse devices impose constraints print never faced. Rigorous evaluation prevents costly mid-project typeface swaps.

Key insights:

  • 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:

Copy patterns:

/* Stress-test at every actual use size */
body { font-size: 16px; }
.caption { font-size: 0.75rem; }
h1 { font-size: 3rem; }

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.

See: references/evaluating-typefaces.md when vetting a candidate face — full quality checklist, red-flags table, and the structural criteria to inspect.

3. Choosing Typefaces

Core concept: Start with purpose, not aesthetics. The content's tone, reading context, and duration should drive selection — not personal preference or trends.

Why it works: Purpose-driven choices feel inevitable rather than arbitrary, and survive stakeholder review because they can be justified with reasoning rather than taste.

Key insights:

  • 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:

Copy patterns:

/* Web font with system fallback stack */
body {
  font-family: 'Source Sans Pro', -apple-system,
               BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
}

See: references/evaluating-typefaces.md when narrowing finalists or weighing free vs. paid faces — the side-by-side comparison method and quality-option shortlists.

4. Pairing Typefaces

Core concept: Successful pairings create clear contrast — faces should be obviously different, not confusingly similar. One to two typefaces maximum.

Why it works: Clear structural contrast (serif + sans, light + bold, humanist + geometric) gives each face a distinct role. Faces that are too similar create tension without purpose — readers sense something is "off" without knowing why.

Key insights:

  • 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:

Copy patterns:

/* Classic serif + sans-serif pairing */
h1, h2, h3 { font-family: 'Playfair Display', Georgia, serif; }
body { font-family: 'Source Sans Pro', -apple-system, sans-serif; }

See: references/pairing-strategies.md when picking a second face — proven combinations, the contrast-type table, and same-designer/superfamily shortcuts.

5. Typographic Measurements

Core concept: Three measurements — font size, line length, and line height — form the foundation of comfortable reading. Getting these right matters more than typeface choice.

Why it works: These measurements govern how the eye tracks across and down text: optimal line length matches the saccade pattern, adequate line height prevents the eye from jumping to the wrong line on the return sweep, and sufficient size makes letterforms recognizable on screen.

Key insights:

  • 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

Product applications:

Copy patterns:

.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 */

See: references/responsive-typography.md when writing the clamp() formulas — how to derive min/preferred/max and viewport-based measurement strategies.

6. Building Type Hierarchies

Core concept: 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.

Why it works: Deliberate, consistent differences between levels let readers grasp page structure at a glance; without hierarchy everything competes and nothing wins.

Key insights:

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers