Density token-model analysis
The evidence produced five recurring models. They overlap in hybrid systems, but each describes a different place where the density decision enters the architecture. These are descriptive categories, not proposed PDS architecture.
Model 1: Curated contextual scale
How it works
A context selects one of a small number of coordinated scale outputs. The system resolves many categories—control geometry, spacing, type, icons, and component layout—while preserving semantic component identity. Values can be designed around a ratio, but are published as curated token tables.
Layers
context scale → foundation/mode values → semantic/component aliases → component CSS
Design consumption
Designers choose the platform/context scale, then use the same component and semantic size inside it. The exact current Spectrum Figma authoring mechanism is not public.
Developer consumption
A provider or scoped theme element activates scale, for example <sp-theme scale="large">. Components inherit CSS custom properties. Explicit component size stays orthogonal.
Coexistence
Possible through nested/scoped contexts, but the design system may still govern scale as a broad platform choice.
Strengths
- Strong answer to “same component, different context.”
- Coordinated changes across geometry, typography, and icons.
- Semantic component APIs do not multiply by product type.
Tradeoffs
- Large token surface and testing matrix.
- A scale context can change many descendants, making mixed surfaces harder to reason about.
- A platform scale does not automatically represent product purpose such as commerce versus enterprise.
Accessibility implications
The larger scale can encode touch-oriented targets; smaller scale still needs explicit hit-area rules. Visual and interactive dimensions should remain separable.
Evidence
Adobe Spectrum is the primary example. Its mobile/large output changes type and icons as well as control dimensions. Spectrum platform scale
Model 2: Numeric density theme with component clamps
How it works
A global numeric density input is transformed into component token values. Each component chooses which metrics respond and clamps the scale at its own usable minimum.
Layers
density number → theme/Sass transform → component density token map → emitted CSS variables → component
Design consumption
Design-tool parity is not necessarily a single variable mode; no public Angular Material mapping was verified.
Developer consumption
Developers configure a theme or emit density-only mixins globally, per component, or under a selector.
Coexistence
Yes, when multiple density outputs are scoped to different selectors. Runtime switching requires pre-emitted styles or regeneration/build conventions.
Strengths
- One compactness input with predictable step semantics.
- Component-specific clamps prevent impossible universal values.
- Can be applied globally or surgically.
Tradeoffs
- The numeric scale can suggest a false uniformity; actual component floors differ.
- Build-generated CSS can make runtime mode switching less direct than inherited custom-property themes.
- Typography may remain independent, so the density number does not describe the whole visual rhythm.
Accessibility implications
Each step needs component-level target analysis. Angular Material’s button keeps a 48px invisible target only for 0/-1 and removes it at -2/-3 to avoid overlap, exposing a real tradeoff rather than guaranteeing touch equivalence.
Evidence
Angular Material is the primary example. Angular Material theming
Model 3: Application density policy with semantic remapping
How it works
An application, platform, organization, or user preference selects compact versus comfortable behavior. Components consume density-aware semantic variables or inherit an ancestor marker. Responsive and component-specific rules handle exceptions.
Layers
Two observed forms:
application density marker → component style query → component-private variables → global theme variables
user preference → alternate semantic/variable-token aliases → component styling
Design consumption
SAP publishes separate Cozy and Compact Figma libraries. Salesforce’s current Figma mechanism is not public.
Developer consumption
SAP applies an application/ancestor class or attribute. Salesforce generally follows the platform preference, while record forms expose density="auto|compact|comfy" and custom styles can consume variable tokens.
Coexistence
Technically possible in both implementations, but governance differs. SAP explicitly prohibits mixing cozy and compact within a page hierarchy. Salesforce allows controlled form/field overrides and responsive fallback around a broader user preference.
Strengths
- Aligns density with input capability or user preference.
- Maintains one component set and one semantic layer.
- Can change layout structure, not only numeric padding.
Tradeoffs
- Broad inherited change can conflict with embedded/local experiences.
- User preference, device capability, and product defaults can compete.
- Public token packages may not expose the full runtime resolver, as in Salesforce.
Accessibility implications
Application policy can choose a touch-safe mode. SAP keeps type size stable and uses a 44px cozy area, while compact assumes pointer/keyboard. Responsive label stacking in Salesforce prevents compact desktop layouts from becoming unreadable in narrow viewports.
Evidence
SAP Fiori/UI5 and Salesforce Lightning. SAP content density Lightning density settings
Model 4: Explicit component size variants
How it works
There is no single density context. Each component exposes the sizes meaningful for its anatomy: Button might have six sizes, Input four, and Table five. Stable foundation tokens are selected inside each size implementation.
Layers
component size prop/property → component size style/class → stable foundation/semantic tokens → component
Design consumption
Designers choose component properties/variants in Figma. Broader productive/expressive or content guidance governs which combinations belong together.
Developer consumption
Developers set props such as size="sm", size="extra-small", or size="large".
Coexistence
Yes by construction. Different component sizes can appear in different regions without providers or theme scopes.
Strengths
- Every component can have an anatomy-appropriate range and labels.
- Easy local coexistence and explicit code review.
- Semantic meaning and visual emphasis stay independent from size.
Tradeoffs
- No automatic product-wide density change.
- Consistency depends on composition rules and disciplined defaults.
- Cross-component size names do not guarantee equal height or equivalent density.
Accessibility implications
Small variants must document input context and target spacing. The smallest Carbon and Fluent controls can be 24px, below their own stronger touch recommendations, so size selection is not input-agnostic.
Evidence
IBM Carbon and Microsoft Fluent 2 Web. Carbon button sizes Fluent design tokens
Model 5: Component-local compact modifier
How it works
Selected data-heavy or container components expose compact, while other components have no density API. A local modifier remaps only that component’s custom properties to other shared semantic-token steps.
Layers
compact prop/modifier → component CSS-variable reassignment → global semantic tokens → component descendants
Design consumption
Designers choose a compact component variant/property where published; there is no global density mode.
Developer consumption
Examples include variant="compact", isCompact, and .pf-m-compact.
Coexistence
Yes. Default and compact components can sit on the same page, subject to component compatibility and composition guidance.
Strengths
- Limits density complexity to components with a demonstrated need.
- Preserves global foundations and avoids broad unintended changes.
- Particularly effective for tables/lists/cards with clear information-density use cases.
Tradeoffs
- Coverage and terminology can be inconsistent across components.
- Local variants do not create a coherent whole-product density by themselves.
- Feature combinations may be unsupported; PatternFly compact tables have restrictions with some expandable patterns.
Accessibility implications
Each modifier must be audited. PatternFly guidance explicitly positions compact tables as a row-count/readability tradeoff and uses responsive restructuring on mobile.
Evidence
PatternFly is the primary example. PatternFly table guidance
Hybrids in the evidence
No mature example is completely pure:
- Spectrum combines contextual scale with explicit semantic component sizes and table row variants.
- Angular Material combines a global numeric scale with component-specific clamps and exclusions.
- Salesforce combines a broad user preference, semantic token remapping, record-form density props, field variants, and responsive fallback.
- Carbon combines component sizes with productive/expressive typography strategy.
- PatternFly has compact components and an expansive Card display variant without a global axis.
“Hybrid” is therefore not a sixth mechanism so much as the common reality that different problem layers need different controls.
What the evidence says about one governed component
All five models can preserve:
same component + same semantic meaning + different density geometry
They differ in who makes the decision:
| Decision owner | Mechanism | Evidence |
|---|---|---|
| Platform/context | Inherited scale tokens | Spectrum |
| Theme author | Numeric density transform | Angular Material |
| Application/user policy | Ancestor marker or semantic alias remap | SAP, Salesforce |
| Component consumer | Explicit size prop | Carbon, Fluent |
| Component consumer for selected patterns | compact modifier | PatternFly |
The governed identity remains stable because semantics, behavior, states, accessibility contract, and source component stay shared. What changes is the geometry-resolution layer. The public systems do not require a second enterprise design system to achieve dense variants; equally, several mature systems intentionally avoid turning every component into a global mode participant.
Categories that actually changed
Across the sample, density-sensitive categories were:
- control/container height and row height
- vertical and horizontal padding, gaps, and margins
- icon size or icon slot size in some systems
- typography size/line height in Spectrum and selectively in Salesforce, Carbon, Fluent, and PatternFly
- component layout logic, such as Salesforce label position and Angular filled-label behavior
- touch/cursor hit area, sometimes separately from visible geometry
Border radius and border width changed far less consistently. Spectrum explicitly keeps border width fixed across scale. Layout grid and responsive breakpoints were generally parallel systems rather than direct density outputs.
Practitioner corroboration
The supplemental practitioner material adds three implementation views without changing the five-model taxonomy:
- SAS demonstrates a domain-based, multi-dimensional token organization (
core,theme,density, andlanguage) and documents the difficulty of making locale typography participate in a uniform compact transform. - Uber demonstrates density selection through a component-specific Figma variable collection. The visible List Item example uses three modes and only three semantic geometry variables; one remains invariant across modes. No downloadable schema or component package is available, and the example does not establish one global density collection.
- Meridian provides inspectable code for subtree-scoped CSS density variables layered with explicit component sizes and a component-local table
denseprop. Because the repository is new, it is implementation evidence rather than a mature adoption benchmark.
See _practitioner-evidence.md for the source-strength assessment and exact caveats.
The normalized exact values for the four deeply inspected implementations are in _implementation-data.json.
Public-documentation gaps
- Exact Figma density implementation is usually less public than code. Only SAP’s separate-library approach was directly documented.
- Salesforce does not expose the full production preference-to-token resolver.
- Cross-platform systems such as Fluent have different implementations by platform; the captured evidence is Web/React only.
- “Compact” is overloaded: it can mean an application input mode, a theme number, a table modifier, or merely a component size. Token names alone are insufficient to infer architecture.