chore(theme): migrate inline layout/typography CSS-var styles to Tailwind #78

Background

Follow-up from a review comment on #76 (discussion) suggesting style={{ paddingInline: "var(--frame-gutter)" }} → className="px-[var(--frame-gutter)]" in Footer.tsx.

#4 only covered the theme color tokens (--color-ink, --color-paper, --color-whisper), which are wired into @theme inline in app/globals.css and auto-generate clean utilities (text-paper, bg-ink, …). The remaining inline-style CSS-var usages are all layout (--frame-*) and typography (--fs-*) tokens that currently live as plain :root custom properties — they don't generate any utilities, so they're stuck as either inline style={{}} or arbitrary-value classes.

Migrating just one site (e.g. only Footer.tsx) breaks consistency with its neighbours, which is why the suggestion was deferred. This issue tracks the broader pass.

In scope (34 sites)

paddingInline: "var(--frame-gutter)" (3)

• components/ui/Frame.tsx:26
• components/site/Footer.tsx:5
• components/site/Chrome.tsx:123

maxWidth: "var(--frame-max)" (3)

• components/ui/Frame.tsx:32
• components/site/Footer.tsx:9
• components/site/Chrome.tsx:127

Other --frame-* inline styles in Frame.tsx (2)

• components/ui/Frame.tsx:25 — minHeight: "min(100svh, var(--frame-min-h-cap))"
• components/ui/Frame.tsx:27 — paddingBlock: "var(--frame-pad-y)"

fontSize: "var(--fs-*)" (28)

Out of scope

• --reveal-delay writes inside style={{}} — these set a CSS var that descendant CSS reads (animation orchestration), not a one-way styling lookup. Keep as inline style.
• scroll-mt-[var(--nav-h)] in Frame.tsx:23 — already a className, not an inline style.
• Color tokens — done in chore(theme): migrate remaining inline var()/style theme colors to Tailwind utilities #4 / chore(theme): migrate inline var() to Tailwind utilities (close #4) #75 / chore(theme): migrate footer to Tailwind theme utilities #76.

Approach (open question)

Two viable directions; the migration looks very different depending on which we pick:

A. Promote tokens into @theme inline with Tailwind v4 namespace names so utilities auto-generate:

• --text-h1, --text-body, … (Tailwind v4 --text-* namespace) → text-h1, text-body
• --spacing-frame-gutter, --max-width-frame, … (similar namespaces) → px-frame-gutter, max-w-frame
• Pro: real utilities, no arbitrary-value classes, IDE autocomplete, doc-friendly.
• Con: renames the public CSS API; any external doc/MDX or docs/ styling referencing var(--fs-h1) etc. needs an alias or a rename.

B. Arbitrary-value classes, keep the var names:

• text-[length:var(--fs-h1)], px-[var(--frame-gutter)], max-w-[var(--frame-max)].
• Pro: single PR, no token rename, no risk to external consumers.
• Con: 34 sites of bracket-soup; defeats some of chore(theme): migrate remaining inline var()/style theme colors to Tailwind utilities #4's "use real utilities" spirit.

Recommendation: A is the more lasting fix; B is reasonable if the deadline pressure is real. Either way it's one bundled PR — partial migration causes the same inconsistency that motivated this issue.

Verification

Same triple as #4:

1. pnpm lint && pnpm exec tsc --noEmit && pnpm build
2. pnpm dev smoke check: hero/h2/h3 sizes unchanged, frame gutter and max width unchanged across §01–§05 and /blog, footer micro-meta size unchanged, no layout shift at viewport breakpoints (@md, @xl, @4xl).
3. Optional: compare out/_next/static/chunks/*.css size before/after — should not balloon.

Links

• Source comment: chore(theme): migrate footer to Tailwind theme utilities #76 (comment)
• Prior color-token migration: chore(theme): migrate remaining inline var()/style theme colors to Tailwind utilities #4, chore(theme): migrate inline var() to Tailwind utilities (close #4) #75, chore(theme): migrate footer to Tailwind theme utilities #76