_comparison

Cross-system comparison

This table normalizes the public evidence without treating unlike concepts as equivalent. “None” means no verified system-wide mechanism was found, not that the system cannot create dense layouts.

Area	Adobe Spectrum	Angular Material	SAP Fiori / UI5	Salesforce Lightning	IBM Carbon	Microsoft Fluent 2 Web	PatternFly
Explicit density model	Yes: platform scale	Yes: density theme dimension	Yes: content density	Yes: user/org UI density plus form density	No global density; sizes and productive/expressive strategy	No verified global web density; component sizes	No global density; local compact modifiers
Number of density levels	2 scales: desktop/mobile (SWC medium/large)	6 theme inputs: 0 to -5; per-component clamping	2: cozy/compact	2 global: Comfy/Compact; form API auto/compact/comfy	3–6 sizes depending on component; 2 type strategies	3 typical sizes; Table has 3 differently named sizes	Usually default/compact where supported; Card also display-lg
Global or component-level	DOM-subtree scale plus independent component size	Global, selector-scoped, or component mixin	Application-level by guidance; ancestor/local technically	Global preference plus component-specific form behavior	Component-level/region strategy	Component-level	Component-level
Spacing changes	Yes, scale-resolved layout/component tokens	Yes, component density token maps	Yes, component dimensions and gaps	Yes, variable general/horizontal/vertical tokens	Size classes select shared spacing/layout values	Per-size component styles select global spacing tokens	Compact modifier remaps component CSS variables
Control height changes	Yes: component-height series	Yes: 4px steps to component-specific floor	Yes: typical 44px cozy to 32px compact rows/toolbars	Some platform/components; public global docs emphasize record layout/spacing more than one universal height	Yes, explicit component sizes	Yes: e.g. Input 24/32/40px	Where component compact variant defines it
Typography changes	Yes: separate scale-resolved font ramps	No automatic change; separate theme dimension	No: same type size	Selectively: titles, line height, selected variable font aliases	By productive/expressive strategy and some sizes	Component-specific: Button changes; Input/Table generally do not	Component-specific: DataList does; Table largely does not
Icon sizing changes	Yes: separate desktop/mobile icon sets	Component-specific; not a universal result of density	Component-specific	Touch/component-specific; no public universal mapping	Component-size-specific	Yes for Button/Input sizes	Component-specific
Table/list density	Multiple row-size token families within each scale	Table header/row heights shrink to scale -4	Global cozy/compact row geometry	Density-aware record UI; public table resolver incomplete	DataTable xs–xl = 24–64px	Table `extra-small	small
Touch target handling	Placement, cursor, and touch areas separated; aims for 48px	Button has 48px invisible target only at 0/-1; removed at denser levels	Cozy 44px area; visual control may be smaller; compact assumes pointer/keyboard	2.75rem tappable tokens and separate touch Sass; 44px mobile guidance	44px icon-target guidance; smallest visual variants can be 24px	44px web/iOS and 48px Android guidance; small targets conditional	Compact guidance acknowledges readability tradeoff; target validation remains contextual
Token mechanism	Mode-set data → scale CSS vars → semantic/component vars	Sass density scale → component token maps → CSS vars	Density marker → style query → private vars → SAP theme vars	Preference → alternate variable-token mapping; component Sass	Stable foundations → component size maps/classes	Global/alias tokens → per-size Griffel styles	Global semantic tokens → component compact custom-property remap
Figma mechanism	Exact current mechanism not public	Exact Angular-to-Figma mapping not public	Separate Cozy and Compact libraries/files	Not public	Component variants/properties; theme modes are separate	Component properties/variants; no public density mode	Component variants/properties; theme variable modes are separate
Code mechanism	`<sp-theme scale=“medium	large”>plus componentsize`	Theme config/Sass density mixins, optionally scoped	sapUiSizeCompact, data-ui5-compact-size, or ancestor density context	Platform preference; form `density=“auto	compact	comfy”`; token use
Can densities coexist?	Technically yes via scoped themes and sizes	Yes via selector/component-scoped generated CSS	Technically yes; design guidance says never mix within one page hierarchy	Partially: global preference plus form/field overrides and responsive fallback	Yes, by component/region	Yes, by component	Yes, by component

Common architectural patterns

1. Density is rarely a raw multiplier

Spectrum has a 1.25 scale principle and Angular Material uses 4px steps, but both still publish curated component outcomes and component-specific bounds. No examined system simply multiplies every spacing, type, icon, radius, and target value by one unrestricted factor.

2. Systems separate semantic identity from geometry

A primary button remains primary while another axis determines geometry: inherited scale in Spectrum, a density token map in Angular Material, or size in Carbon and Fluent. PatternFly similarly keeps table semantics stable while adding a compact modifier. Density and semantic meaning are orthogonal in all strong examples.

3. The inheritance boundary is a governance decision

• Spectrum permits a DOM-scoped inherited scale.
• Angular Material can generate global, selector, or per-component density CSS.
• SAP implements ancestor resolution but explicitly governs density at application level and prohibits mixed page hierarchies.
• Carbon, Fluent, and PatternFly avoid a universal inherited switch, making local coexistence easy but leaving consistency to component/composition rules.

The technical ability to scope density does not imply that arbitrary mixing is sanctioned.

4. Typography has three distinct treatments

1. Scale with geometry: Spectrum changes type and icons with platform scale.
2. Independent axis: Angular Material and SAP keep the density change separate from typography; SAP explicitly keeps font size constant.
3. Selective/local change: Salesforce, Carbon, Fluent, and PatternFly change type only for chosen roles, use cases, or component sizes.

This is a major architectural fault line: “compact” does not predict smaller text.

5. Touch safety is not implied by density tokens

Several systems separate visual bounds from interactive bounds, but only in defined conditions. Spectrum models separate hit areas; SAP says a visible control can be smaller than its touch area; Angular retains a 48px invisible button target at mild density but removes it when overlap would occur. WCAG 2.2 AA is 24px or sufficient spacing with exceptions, while 44px is AAA, so product guidance often exceeds the normative minimum. WCAG 2.5.8 WCAG 2.5.5

6. Data-heavy components often need their own density axis

Spectrum tables have regular/spacious row families inside each platform scale; Carbon and Fluent expose multiple table sizes; PatternFly has a compact table modifier. This prevents an application-wide choice from being the only way to tune row count, multi-line content, and action cells.

7. Figma architecture is less public than code architecture

SAP is the clearest verified design-tool example and publishes separate Cozy and Compact libraries. Carbon, Fluent, and PatternFly publicly map component configurations to variants/properties. None of the researched sources establishes that a global Figma variable mode is the inevitable counterpart of code density. For Spectrum, Angular Material, and Salesforce, exact current authoring mechanisms are not public enough to verify.

The “same component + same meaning + different context” boundary

The systems demonstrate three factual ways to preserve one governed component:

• Inherited contextual resolution: Spectrum’s same semantic component resolves through a scale scope; Angular Material can do the same through scoped density CSS.
• Application policy with constrained exceptions: SAP changes the same controls through application density but forbids mixing; Salesforce follows a user preference while form components and responsive rules add controlled exceptions.
• Explicit component geometry: Carbon, Fluent, and PatternFly keep one Button/Table/List API and expose a size or compact modifier instead of a global mode.

The latter group is direct evidence that a mature system can intentionally avoid theme/mode architecture. It preserves component governance through shared code, tokens, states, and semantics while making geometry an explicit component/composition decision.

Supplemental implementation evidence

These sources add implementation specificity but are kept separate from the seven-system maturity table:

Area	Uber demo	SAS case study	Meridian source
Evidence type	Primary video showing Figma UI	Practitioner-authored implementation account	Public code/token source; limited adoption evidence
Modes	Default / Compact / Spacious	Standard / Compact / Comfortable; developer medium / high / low	Default/comfortable + Compact
Granularity	Component-specific List Item variable collection inherited by frame	Independent product density dimension	Ancestor/subtree scope plus component size and local Table prop
Exact public data	3 List Item variables, all mode values	Type example: 14px default, 12px compact, selected locales 16px	5 CSS variables with default/compact values
Typography	Not exposed in density collection shown	Intended to change with 12px floor; locale overrides may win	Global compact does not change type; local Table dense does
Separate theme axis	Yes, visible on frame	Yes, independent collection/load layer	Yes, separate data-theme attribute
Main implementation lesson	Figma modes can carry component-semantic geometry; this does not prove one global density collection	File precedence and locale interaction are part of the architecture	Inheritance, explicit size, and local overrides coexist, but interactions need normalization

Exact values and evidence limits for the three supplemental systems and Spectrum are normalized in _implementation-data.json. The token-library manifest indexes normalized extracts for all ten systems.

Sources and related files

See all ten reports in systems/, including the three supplemental reports, and each pinned inventory or provenance record in sources/. Cross-system accessibility thresholds use W3C WCAG 2.2 Target Size (Minimum).

• Density token-model analysis
• Practitioner evidence assessment
• Comparative token library
• Research index