Boundaries

The typography system is split into three layers with strict responsibilities.

Global baseline

The baseline owns the minimum needed to make plain HTML readable. It applies everywhere — cards, dialogs, heroes, app shells — not only in prose. It does not own visual hierarchy. No global font-size on headings, no global font-weight on headings, no global margins on headings, no global text-decoration on links. These choices would shape app UI in ways the framework cannot predict. The only mildly opinionated defaults at the baseline are: line-height on headings (tight, so multi-line headings stay readable), text-wrap: balance on headings where supported, the hr rule, the ::selection rule, the code / kbd / samp / pre font family, and small font size. Everything else stays neutral so components and .prose can take over without fighting the baseline. Global links inherit color. The visual affordance of a link is the responsibility of .prose (for authored content) or of a component (for nav links, button-like links, tabs, breadcrumbs, etc.). Underlining every a globally would collide with all of those.

.prose scope

.prose is the opt-in rich-text scope. It owns the visual hierarchy of authored content. It owns: readable measure, vertical rhythm between common text elements, heading hierarchy, link affordance, list spacing, code and keyboard treatment, blockquote treatment, table treatment, image / figure / figcaption treatment, mark, and text-wrap balance / pretty for prose elements. It does not own: page layout, app cards, alerts, forms, app tables, navigation, component variants, or any automatic styling outside the .prose subtree. The reason for that boundary: a dialog title, a card heading, or a sidebar section heading should not become a "prose h1". Components own those. If a card or a dialog wants a richer heading, it can use a component-level rule, not a global selector.

Optional fluid module

src/css/optional/typography-fluid.css is a small file that is not imported by actual.css. Projects that need display, title, and lead sizes that scale with the viewport (landing pages, marketing pages, hero sections, documentation homepages) import it manually after actual.css. The module exposes three size tokens (--fluid-display, --fluid-title, --fluid-lead) and three composed classes (.text-display, .text-title, .text-lead). It is deliberately not the foundation: body text, app UI, and the default prose scale stay static. There is also a non-fluid .lead utility in the core, for a simple readable intro paragraph. The optional module does not redefine .lead; it adds a separate .text-lead for display contexts. This avoids an optional import silently changing how existing markup renders.