Personal Research

salesforce-lightning

4 min read

Salesforce Lightning

1. Why this system is relevant

Salesforce Lightning Experience added a user-selectable global density while retaining one component system. Its mechanism combines remapped variable tokens, record-form layout behavior, responsive fallback, and touch-specific component styles. It is a strong example of density affecting both spacing and selected typography rather than uniformly scaling every component.

2. Density terminology

Lightning Experience uses Comfy and Compact. Public component APIs also use auto, compact, and comfy for form density. Older organizational settings may use Cozy, but the lightning-record-*-form density attribute does not accept cozy. Lightning density launch Record-form density

3. Density model

  • Lightning Experience has an organization default and a per-user density preference.
  • Global Comfy/Compact changes record-page information density through variable spacing, line height, label alignment, and title size.
  • Record form components expose density="auto|compact|comfy". auto follows the user setting; explicit values control label alignment, but the documentation warns that overriding a form’s density does not automatically change all spacing.
  • Individual fields can override label presentation through component variants.
  • Narrow compact forms responsively stack labels in a comfy-like arrangement to avoid unusable horizontal layouts. Record-form density

4. Token architecture

The public token evidence is:

user/org density setting → alternate variable-token mapping → component Sass/token consumption

Base spacing tokens retain their values. Density-aware VAR_SPACING_*, horizontal, and vertical aliases resolve to smaller steps in the compact documentation mapping. Selected VAR_FONT_SIZE_* aliases also remap. Components opt into the behavior by consuming variable tokens; constant spacing tokens do not change. Record forms add a component API/layout layer on top.

The public repository labels design-tokens/var-spacing.yml as documentation-site-only, so it proves the mapping model and values but not the complete production resolver.

The public launch article documents varSpacingMedium changing from 1rem / 16px in Comfy to 0.5rem / 8px in Compact. The pinned compact mapping includes:

Variable tokenCompact alias
VAR_SPACING_MEDIUMSPACING_X_SMALL (0.5rem)
VAR_SPACING_LARGESPACING_SMALL
VAR_SPACING_HORIZONTAL_MEDIUMSPACING_SMALL
VAR_SPACING_VERTICAL_MEDIUMSPACING_X_SMALL
VAR_FONT_SIZE_5FONT_SIZE_4
VAR_FONT_SIZE_6FONT_SIZE_5
VAR_FONT_SIZE_8FONT_SIZE_7

The directional mappings deliberately differ, allowing vertical rhythm to tighten more than horizontal spacing. Primitive touch tokens include SQUARE_TAPPABLE and HEIGHT_TAPPABLE at 2.75rem, plus smaller 2rem, 1.5rem, and 1.25rem variants for defined contexts. Density token article var-spacing.yml touch.yml

6. Typography behaviour

Typography changes selectively. The launch guidance identifies smaller titles and tighter line height in Compact; its example changes a title from 1rem to 0.875rem and line height from 1.5 to approximately 1.3/normal. The token mapping confirms selected font roles step down while others stay fixed. This is neither a wholly separate type ramp nor “spacing only.” Lightning density launch

7. Representative component examples

  • Record forms/fields: density primarily changes horizontal versus stacked labels; narrow containers reflow labels.
  • Cards/record regions: launch examples tighten card padding from 1rem to 0.5rem vertically and 0.75rem horizontally and reduce title size.
  • Tables: source consumes a component TABLE_CELL_SPACING token and inherits body type; full production density remapping is not exposed in the repo.
  • Buttons/inputs: base and touch Sass are separate; touch styles raise control line height/target geometry through tappable tokens.
  • Dialogs/navigation: no public evidence was found for a single cross-component density prop; they participate when their CSS consumes density-aware tokens or platform styles.

8. Design/Figma implementation

No official public documentation was found that reveals whether Lightning’s current Figma libraries implement Comfy/Compact with variables, variants, or separate libraries. The public token repository and runtime docs do not justify inferring a Figma mode architecture.

9. Code implementation

Record form activation is component-specific:

<lightning-record-edit-form density="compact">
  <lightning-input-field field-name="Name"></lightning-input-field>
</lightning-record-edit-form>

For density-aware custom styling, historical guidance uses variable tokens such as t(varSpacingMedium) rather than hard-coded spacing. The platform resolves the user preference; the public source does not expose that complete runtime path. Record-form density

10. Accessibility constraints

Salesforce separates desktop density from mobile/touch styling. Public button guidance recommends at least 44 × 44px for mobile targets, and the source provides 2.75rem tappable tokens. Compact record-form labels reflow in narrow containers, supporting readability and zoom/reflow rather than preserving a cramped side-by-side layout. Lightning button guidance Record-form density

11. Limitations / unavailable evidence

  • var-spacing.yml explicitly says it is used only on the documentation site; it should not be presented as the entire Lightning production implementation.
  • The full preference-to-theme resolver and current Figma authoring architecture are not public.
  • Form density controls label structure more directly than generic spacing, so it is not equivalent to a universal subtree theme.
  • Public density material dates to Lightning’s 2018 rollout; current component behavior was cross-checked in current LWC documentation, but the global implementation remains opaque.

Graph View

Backlinks