From e818c14ff11b55054ba917e8cacb74b8c3cbafd5 Mon Sep 17 00:00:00 2001 From: Paul Bakaus Date: Tue, 17 Mar 2026 08:18:15 -0700 Subject: [PATCH] Distinguish fluid vs fixed type scales for apps vs content pages The typeset skill universally recommended fluid sizing via clamp(), but no major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI. Now recommends fixed rem scales for app UIs and reserves fluid type for marketing/content page headings. Co-Authored-By: Claude Opus 4.6 (1M context) --- .claude/skills/frontend-design/reference/typography.md | 6 ++++-- .claude/skills/typeset/SKILL.md | 5 +++-- source/skills/frontend-design/reference/typography.md | 6 ++++-- source/skills/typeset/SKILL.md | 5 +++-- 4 files changed, 14 insertions(+), 8 deletions(-) diff --git a/.claude/skills/frontend-design/reference/typography.md b/.claude/skills/frontend-design/reference/typography.md index 8cce06a12..fc201c8a6 100644 --- a/.claude/skills/frontend-design/reference/typography.md +++ b/.claude/skills/frontend-design/reference/typography.md @@ -86,9 +86,11 @@ Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these override ### Fluid Type -Use `clamp(min, preferred, max)` for fluid typography. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens. +Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens. -**When NOT to use fluid type**: Button text, labels, UI elements (should be consistent), very short text, or when you need precise breakpoint control. +**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes. + +**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it. ### OpenType Features diff --git a/.claude/skills/typeset/SKILL.md b/.claude/skills/typeset/SKILL.md index d768c3f7b..60f41ed35 100644 --- a/.claude/skills/typeset/SKILL.md +++ b/.claude/skills/typeset/SKILL.md @@ -33,7 +33,7 @@ Analyze what's weak or generic about the current type: 3. **Sizing & scale**: - Is there a consistent type scale, or are sizes arbitrary? - Does body text meet minimum readability? (16px+) - - Is fluid sizing used, or do sizes jump at breakpoints? + - Is the sizing strategy appropriate for the context? (Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings) 4. **Readability**: - Are line lengths comfortable? (45-75 characters ideal) @@ -73,7 +73,8 @@ Build a clear type scale: - **5 sizes cover most needs**: caption, secondary, body, subheading, heading - **Use a consistent ratio** between levels (1.25, 1.333, or 1.5) - **Combine dimensions**: Size + weight + color + space for strong hierarchy — don't rely on size alone -- **Use fluid sizing**: `clamp(min, preferred, max)` for smooth scaling +- **App UIs**: Use a fixed `rem`-based type scale, optionally adjusted at 1-2 breakpoints. Fluid sizing undermines the spatial predictability that dense, container-based layouts need +- **Marketing / content pages**: Use fluid sizing via `clamp(min, preferred, max)` for headings and display text. Keep body text fixed ### Fix Readability diff --git a/source/skills/frontend-design/reference/typography.md b/source/skills/frontend-design/reference/typography.md index 8cce06a12..fc201c8a6 100644 --- a/source/skills/frontend-design/reference/typography.md +++ b/source/skills/frontend-design/reference/typography.md @@ -86,9 +86,11 @@ Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these override ### Fluid Type -Use `clamp(min, preferred, max)` for fluid typography. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens. +Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens. -**When NOT to use fluid type**: Button text, labels, UI elements (should be consistent), very short text, or when you need precise breakpoint control. +**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes. + +**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it. ### OpenType Features diff --git a/source/skills/typeset/SKILL.md b/source/skills/typeset/SKILL.md index 2bf23e183..29cf689a9 100644 --- a/source/skills/typeset/SKILL.md +++ b/source/skills/typeset/SKILL.md @@ -33,7 +33,7 @@ Analyze what's weak or generic about the current type: 3. **Sizing & scale**: - Is there a consistent type scale, or are sizes arbitrary? - Does body text meet minimum readability? (16px+) - - Is fluid sizing used, or do sizes jump at breakpoints? + - Is the sizing strategy appropriate for the context? (Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings) 4. **Readability**: - Are line lengths comfortable? (45-75 characters ideal) @@ -73,7 +73,8 @@ Build a clear type scale: - **5 sizes cover most needs**: caption, secondary, body, subheading, heading - **Use a consistent ratio** between levels (1.25, 1.333, or 1.5) - **Combine dimensions**: Size + weight + color + space for strong hierarchy — don't rely on size alone -- **Use fluid sizing**: `clamp(min, preferred, max)` for smooth scaling +- **App UIs**: Use a fixed `rem`-based type scale, optionally adjusted at 1-2 breakpoints. Fluid sizing undermines the spatial predictability that dense, container-based layouts need +- **Marketing / content pages**: Use fluid sizing via `clamp(min, preferred, max)` for headings and display text. Keep body text fixed ### Fix Readability