Personal Research

adobe-spectrum

6 min read

Adobe Spectrum

1. Why this system is relevant

Spectrum is the clearest public example of the same governed components being re-resolved for two platform/input contexts. Its design data explicitly models scale as a mode set, while Spectrum Web Components (SWC) exposes the result at runtime through a DOM-scoped theme element. It also keeps semantic component size (s, m, l, xl) separate from platform scale.

2. Density terminology

Spectrum calls the design concept platform scale: desktop and mobile. Its token source names the modes desktop and mobile; SWC’s public runtime API calls the corresponding output medium and large. Spectrum’s data specification describes scale as a “mode set” and also calls it a density scale. Platform scale Mode-set specification

3. Density model

  • Two context-wide scales: desktop/medium and mobile/large.
  • Mobile uses a 1:1.25 proportion relative to desktop. Typography and icons have scale-specific ramps; border width intentionally does not scale.
  • Guidance ties the selection primarily to platform, viewport, and input context, not to commerce versus enterprise. Hybrid environments are expected to accommodate both.
  • SWC can scope scale to an <sp-theme> subtree. Nested theme scopes therefore allow distinct regions technically, although Spectrum’s guidance frames scale as a platform/context decision rather than arbitrary local decoration.
  • Component size remains an independent axis. A size="s" control can exist in either scale. Platform scale SWC theme API SWC sizing example

4. Token architecture

The source separates mode metadata, foundation tokens, semantic/component tokens, and generated CSS:

scale mode → scale-specific foundation CSS variables → semantic/component variables → component CSS

packages/design-data/mode-sets/scale.json declares the desktop/mobile modes. registry/scale-values.json contains per-scale values. Component JSON files alias layout and typography tokens. SWC packages publish medium-vars.css and large-vars.css, and components consume custom properties such as component height, edge-to-text, font size, and icon size. Design-data token format SWC tokens

Selected generated SWC values from the pinned source:

TokenMediumLarge
--spectrum-component-height-10032px40px
--spectrum-component-height-20040px50px
--spectrum-component-height-30048px60px
--spectrum-font-size-10014px17px
--spectrum-font-size-20016px19px
--spectrum-font-size-30018px22px

The full component-height series changes from 20, 24, 32, 40, 48, 56, 64px to 26, 30, 40, 50, 60, 70, 80px. The generated font ramp changes from 11–60px to 13–70px. These are curated scale outputs rather than a browser-applied multiplier. Source: medium-vars.css and large-vars.css.

Affected categories include component heights, spacing/padding, typography size and line height, icon size, corner radius, and component-specific layout. Border widths are deliberately stable across platform scale. Table source also provides independent compact, regular, and spacious row-height token families within each platform scale, showing that table density is not collapsed into the platform-scale axis.

Exact scale × component-size composition

The component schemas make the composition explicit. Button and Text Field expose s, m, l, and xl, which bind the 75/100/200/300 metric slots:

Metric familySize slotsMedium / desktopLarge / mobile
Component height75, 100, 200, 30024, 32, 40, 48px30, 40, 50, 60px
Component edge-to-text75, 100, 200, 30010, 12, 15, 17px13, 15, 18, 22px
Pill edge-to-text75, 100, 200, 30013, 16, 20, 23px17, 20, 24, 30px
Font size75, 100, 200, 30012, 14, 16, 18px15, 17, 19, 22px
Text line height75, 100, 200, 30016, 18, 20, 22px20, 22, 24, 26px
Workflow icon size75, 100, 200, 30016, 20, 22, 26px18, 24, 28, 30px

For example, Button / m binds component-height-100, font-size-100, workflow-icon-size-100, and the matching pill edge-to-text slot. Changing platform scale re-resolves all four while the component remains size m.

Table adds a second, component-local density dimension. For a medium-size row:

Table densityMedium scaleLarge scaleTypography
Compact32px40pxfont-size-100
Regular40px50pxfont-size-100
Spacious48px60pxfont-size-100

Compact row height aliases component-height-100; regular and spacious use explicit table row-height output. The table schema says density changes vertical spacing while keeping font size consistent. Platform scale still changes font-size-100 itself from 14px to 17px. Spectrum therefore has two independent decisions: platform scale changes the full metric system, while Table density changes row geometry inside the selected platform scale.

6. Typography behaviour

Typography changes with platform scale: mobile text is larger. Spectrum publishes separate scale-resolved font-size and line-height variables, and icon sets scale too. This differs from systems that compact only surrounding whitespace. The semantic type role remains the same while its resolved metrics change. Platform-scale typography

7. Representative component examples

  • Button: component JSON aliases scale-sensitive heights, edge-to-text, text, and icon metrics; SWC CSS consumes those variables without creating a second button identity.
  • Text field / picker: height, horizontal padding, label/value metrics, and icon dimensions resolve through scale output.
  • Table/list: row component tokens include multiple semantic row sizes; scale then resolves their actual metrics.
  • Card/dialog: component JSON uses shared spacing/layout aliases, so scale can affect composed surfaces without a component-specific compact prop.

Representative pinned source: button.json, table.json, and spectrum-button-base.css.

8. Design/Figma implementation

Spectrum’s public design guidance and token schema clearly define desktop/mobile scale, but the exact current Figma-library mechanism—variable mode, component property, or separate library—is not publicly documented in enough detail to verify. This report therefore does not map Spectrum’s token mode set directly to a Figma variable mode.

9. Code implementation

SWC activates scale through the theme element:

<sp-theme system="spectrum" color="light" scale="large">
  <sp-button size="m">Continue</sp-button>
</sp-theme>

Theme.ts validates medium | large, attaches scale styles, and lets CSS custom properties inherit through the subtree. The button’s size is separate from the theme’s scale. Theme.ts

10. Accessibility constraints

Spectrum distinguishes placement area, cursor hit area, and touch hit area. Touch hit areas attempt to reach at least 48 × 48px even when the visible geometry differs. Desktop scale is cursor-primary and mobile scale touch-primary, but both are designed to support both input families. Browser zoom and responsive layout remain separate concerns. Platform-scale hit areas

11. Limitations / unavailable evidence

  • The design-data names (desktop/mobile) and SWC names (medium/large) are not identical; they should not be treated as a universal vocabulary.
  • The 1.25 relationship is a design principle, but published token values are curated and rounded rather than a single runtime multiplier.
  • Exact current Figma implementation is not public enough to verify.
  • The evidence supports platform/input scale, not a declared commerce/enterprise product theme.

The current design-data Table schema exposes compact, regular, and spacious; the captured first-generation generated CSS resolves compact partly through aliases in global-vars.css. Consumers must inspect both global and scale-specific output rather than expecting every compact value to be duplicated in each scale file.

Graph View

Backlinks