@halogen-ui/tokens 0.1.0

package/src/primitives/color.ts

@@ -0,0 +1,404 @@
+/**
+ * Halogen — color primitives (layer 1 of 2).
+ *
+ * Authored as OKLCH specifications and *derived* into sRGB, rather than
+ * authored as hex. Three reasons this matters:
+ *
+ *  1. Perceptual spacing. Even steps in OKLCH L are even steps to the eye;
+ *     even steps in hex are not.
+ *  2. Contrast solving. Several values here cannot be chosen by taste — they
+ *     are the answer to "the most vivid step that still clears 4.5:1". Those
+ *     are solved at build time, not guessed.
+ *  3. Auditability. A reviewer can see the intent (lightness, hue, how much of
+ *     the available chroma) instead of an opaque six-digit number.
+ *
+ * Nothing in this file is a semantic decision. No token here knows what a
+ * "button" or an "error" is — that is `src/semantic/`. This layer only answers
+ * "what colors exist".
+ */
+import { hexToOklch, type Oklch } from '../color/oklch.js';
+
+/* -------------------------------------------------------------------------- */
+/* Neutrals                                                                    */
+/* -------------------------------------------------------------------------- */
+
+/**
+ * The neutral ramp is warmed to hue 75° at very low chroma — imperceptible as
+ * color, perceptible as warmth. This is what stops a near-black UI reading as
+ * blue-gray "developer tool" and keeps the grays in the same world as the
+ * orange. Chroma rises slightly toward the dark end, where the warmth does the
+ * most work, and falls to zero at pure white.
+ *
+ * L values are anchored to the brand brief. Three were adjusted to satisfy the
+ * ">= 0.04 L between adjacent surfaces" rule from the aesthetic direction; every
+ * adjustment is listed in `BRIEF_ANCHORS` below and reported in the build's
+ * contrast report rather than being made silently.
+ */
+export const NEUTRAL_HUE = 75;
+
+export const neutral: Record<string, Oklch> = {
+  0: { l: 1.0, c: 0, h: NEUTRAL_HUE },
+  25: { l: 0.978, c: 0.002, h: NEUTRAL_HUE },
+  50: { l: 0.952, c: 0.003, h: NEUTRAL_HUE },
+  100: { l: 0.915, c: 0.004, h: NEUTRAL_HUE },
+  200: { l: 0.862, c: 0.004, h: NEUTRAL_HUE },
+  300: { l: 0.786, c: 0.004, h: NEUTRAL_HUE },
+  400: { l: 0.724, c: 0.004, h: NEUTRAL_HUE },
+  450: { l: 0.668, c: 0.004, h: NEUTRAL_HUE },
+  500: { l: 0.634, c: 0.004, h: NEUTRAL_HUE },
+  /**
+   * The control border, in BOTH themes.
+   *
+   * Solved rather than picked: this is the softest a control boundary can be
+   * while still clearing WCAG 1.4.11's 3:1 against every surface a control sits
+   * on — 3.5:1 on the dark fill, 4.0:1 on the light one. It is deliberately the
+   * same value in both themes, because a mid gray is the one border that reads
+   * as quiet against a near-black fill and against an off-white one.
+   *
+   * It cannot go softer. A filled control identifies itself at only 1.28:1
+   * (dark) and 1.12:1 (light) against the page, so the border is the only thing
+   * that makes an input findable.
+   */
+  550: { l: 0.58, c: 0.005, h: NEUTRAL_HUE },
+  600: { l: 0.532, c: 0.005, h: NEUTRAL_HUE }, // solved: 4.58:1 on neutral-50, the light page ground — at 0.548 it read 4.27 and failed there while passing on white
+  700: { l: 0.44, c: 0.005, h: NEUTRAL_HUE },
+  800: { l: 0.345, c: 0.005, h: NEUTRAL_HUE },
+  850: { l: 0.3, c: 0.005, h: NEUTRAL_HUE },
+  900: { l: 0.274, c: 0.005, h: NEUTRAL_HUE },
+  950: { l: 0.227, c: 0.005, h: NEUTRAL_HUE },
+  1000: { l: 0.176, c: 0.005, h: NEUTRAL_HUE },
+};
+
+/**
+ * The hexes named in the brand brief, kept so the build can report exactly how
+ * far the derived ramp moved from them and why. The brief states these are
+ * "aesthetic references, not final production tokens" — this is the audit trail
+ * for taking it at its word.
+ */
+export const BRIEF_ANCHORS: Array<{
+  name: string;
+  hex: string;
+  mapsTo: string;
+  note?: string;
+}> = [
+  { name: 'White', hex: '#FFFFFF', mapsTo: 'neutral-0' },
+  {
+    name: 'Soft White',
+    hex: '#F3F3F1',
+    mapsTo: 'neutral-50',
+    note: 'Lightened→deepened by 0.012 L. At the brief value the light-mode page ground sat only 0.036 L from a white card — below the 0.04 surface-separation rule, so cards would go mushy on cheap panels.',
+  },
+  { name: 'Muted Gray', hex: '#8A8A8A', mapsTo: 'neutral-500', note: 'L preserved exactly.' },
+  {
+    name: 'Surface Dark',
+    hex: '#252525',
+    mapsTo: 'neutral-900',
+    note: 'Lifted 0.009 L. At the brief value it sat 0.038 L from Deep Charcoal — below the 0.04 surface-separation rule.',
+  },
+  { name: 'Deep Charcoal', hex: '#1C1C1C', mapsTo: 'neutral-950', note: 'L preserved exactly.' },
+  { name: 'Near Black', hex: '#101010', mapsTo: 'neutral-1000', note: 'L preserved exactly.' },
+];
+
+/* -------------------------------------------------------------------------- */
+/* Brand accents                                                               */
+/* -------------------------------------------------------------------------- */
+
+/**
+ * Accent tiers, from the aesthetic direction §3. The tier decides how many
+ * steps get generated — not every accent needs a full ramp, and generating one
+ * anyway is exactly the checklist-satisfying bloat the audit framework warns
+ * against.
+ *
+ *  - `primary`    full set. The one accent that carries interaction.
+ *  - `expressive` anchor + hover/active + a light-mode-safe step. These live in
+ *                 gradients, fills and charts; they never carry interaction.
+ *  - `semantic`   full set, and removed from decorative use entirely.
+ */
+export type AccentTier = 'primary' | 'expressive' | 'semantic';
+
+export interface AccentSpec {
+  /** The brand hex, preserved exactly as the `base` step. */
+  anchor: string;
+  tier: AccentTier;
+  /** Why this color exists — carried into the generated docs. */
+  role: string;
+}
+
+export const accents: Record<string, AccentSpec> = {
+  orange: {
+    anchor: '#FF641F',
+    tier: 'primary',
+    role: 'The single primary accent. Interaction, focus, progress, chart series 1.',
+  },
+  coral: {
+    anchor: '#FF493F',
+    tier: 'expressive',
+    role: 'Gradient stop, feature surface, chart series 5. Never a status color.',
+  },
+  amber: {
+    anchor: '#FF9F00',
+    tier: 'expressive',
+    role: 'Gradient stop, feature surface, progress. Never a status color.',
+  },
+  yellow: {
+    anchor: '#FFD21A',
+    tier: 'expressive',
+    role: 'Gradient stop, high-emphasis promo, chart series 3.',
+  },
+  peach: {
+    anchor: '#FFB46B',
+    tier: 'expressive',
+    role: 'Gradient stop, soft surface, chart series 6.',
+  },
+  pink: {
+    anchor: '#E8A6D8',
+    tier: 'expressive',
+    role: 'Chart series 4, secondary gradient stop.',
+  },
+  teal: {
+    anchor: '#22B8A8',
+    tier: 'semantic',
+    role: 'Status: info. Chart series 2. Removed from decorative use.',
+  },
+};
+
+/* -------------------------------------------------------------------------- */
+/* Status hues                                                                 */
+/* -------------------------------------------------------------------------- */
+
+/**
+ * Status colors are authored independently of the brand accents and live in
+ * their own namespace. This is the single most important decision in the color
+ * system (aesthetic direction §5): the brand owns orange, amber, yellow and
+ * coral, which is precisely where warning and error normally live. Aliasing a
+ * status to a brand accent would make an expressive highlight indistinguishable
+ * from an error.
+ *
+ * `minDeltaFromBrand` is asserted at build time against every brand accent, so
+ * the separation is a checked invariant rather than an intention.
+ */
+export interface StatusSpec {
+  /** Authored directly in OKLCH — chosen for separation, not sampled from a swatch. */
+  base: Oklch;
+  role: string;
+  /** Minimum Oklab distance required from every brand accent anchor. */
+  minDeltaFromBrand: number;
+  /**
+   * What text sits on this color used as a solid fill.
+   *
+   * This is a *recognition* mechanism, not just a contrast one. Every brand
+   * warm fill takes a near-black label. `status-error` is the one fill in the
+   * system that takes white — which means a destructive button and an
+   * expressive coral surface can never be confused, because they are
+   * structurally different objects, not merely different hues.
+   *
+   * That matters because the probe proved no red exists that is both legible
+   * on near-black AND perceptually distant from brand coral: coral occupies
+   * exactly that region of the space. Separating by lightness and label color
+   * solves what separating by hue could not.
+   */
+  onSolid: 'near-black' | 'white';
+}
+
+export const status: Record<string, StatusSpec> = {
+  success: {
+    // Hue 140 — the brand owns no green, so this region is unambiguous. Pushed
+    // toward yellow-green rather than blue-green for two reasons: it belongs to
+    // a warm palette, and it buys separation from teal/info. Green-vs-teal is a
+    // genuinely hard discrimination, especially for deuteranopes, so the
+    // distance is an asserted invariant rather than a hope.
+    base: { l: 0.745, c: 0.19, h: 140 },
+    role: 'Success, confirmation, healthy state.',
+    minDeltaFromBrand: 0.12,
+    onSolid: 'near-black',
+  },
+  warning: {
+    // Deliberately desaturated and lightened away from brand amber (#FF9F00,
+    // L 0.782 C 0.172 H 67.6). Convention requires warning read as amber, so
+    // separation comes from chroma and lightness — reinforced by the mandatory
+    // triangle icon, and by the rule that brand amber never appears as a chip.
+    base: { l: 0.75, c: 0.115, h: 78 },
+    role: 'Warning, caution, degraded state. Always paired with a triangle icon.',
+    minDeltaFromBrand: 0.06,
+    onSolid: 'near-black',
+  },
+  error: {
+    // Authored as an exact brand hex rather than a derived triple, so the value
+    // ships precisely as specified. Everything downstream — the text steps, the
+    // chip surfaces, the boundaries — is still solved from it.
+    //
+    // Still the resolution of the brand/semantic collision: materially darker
+    // than brand coral (L 0.667) and the only fill in the system carrying a
+    // white label. Chasing hue separation failed — at every lightness that
+    // clears 4.5:1 on near-black a red sits within ΔE 0.08 of coral, and
+    // pushing toward magenta stops reading as "error". Going darker inverts the
+    // label color, separating error from every brand fill structurally rather
+    // than chromatically.
+    base: hexToOklch('#CD1F2C'),
+    role: 'Error, destructive action, failed state. The one white-label fill.',
+    minDeltaFromBrand: 0.09,
+    onSolid: 'white',
+  },
+};
+
+/**
+ * The single declared exception to "no status token may alias a brand accent".
+ *
+ * `status-info` IS teal. Generating a second, identical set of teal primitives
+ * under a status name would be pure duplication — nine tokens with the same
+ * values and a different label, which the audit framework rightly treats as a
+ * defect. So info aliases teal in the semantic layer instead.
+ *
+ * The exception is safe only because it is *declared and bounded*: a test
+ * asserts this list has exactly one entry, so a future "warning aliases amber"
+ * cannot be slipped in beside it. That is the difference between an exception
+ * and a loophole.
+ */
+export const STATUS_ALIAS_EXCEPTIONS: ReadonlyArray<{ status: string; accent: string; why: string }> = [
+  {
+    status: 'info',
+    accent: 'teal',
+    why: 'Teal is removed from decorative use entirely and exists to carry the info role. One value, one name.',
+  },
+];
+
+/* -------------------------------------------------------------------------- */
+/* Derivation targets                                                          */
+/* -------------------------------------------------------------------------- */
+
+/**
+ * Interaction washes — translucent, not opaque.
+ *
+ * An opaque hover fill has to name a surface, and `surface-subtle` happens to be
+ * the same value as `surface-floating`. So a ghost button inside a dialog, and
+ * every dropdown-menu item, hovered to exactly the color they were already
+ * sitting on: the state existed, was tested, and was invisible.
+ *
+ * A translucent wash lightens or darkens whatever is underneath it, so one token
+ * works on the page, on a card, and inside an overlay. This is the only place
+ * Halogen uses alpha for a fill, and it is why.
+ */
+export const stateWash: Record<string, string> = {
+  'hover-dark': '#FFFFFF14',
+  'active-dark': '#FFFFFF24',
+  'hover-light': '#0000000F',
+  'active-light': '#0000001A',
+  /** The soft halo behind a focused field. */
+  'focus-glow': '#FF641F3D',
+  /**
+   * Text selection. The browser default is a blue-gray that belongs to no
+   * design system and reads as an accident on a warm palette.
+   *
+   * A translucent accent rather than a solid one, so the selected text keeps
+   * its own color and stays legible over either ground — a solid selection
+   * fill would need a matching text color per theme and would still collide
+   * with any colored text it happened to cover.
+   */
+  'selection-dark': '#FF641F59',
+  'selection-light': '#FF641F52',
+};
+
+/** How far the scrim blurs behind a modal surface. */
+export const SCRIM_BLUR = '5px';
+
+/**
+ * Opacity of the flat scrim that makes light text legal over a gradient.
+ *
+ * MEASURED, not chosen. The worst case is not a gradient at all — it is the
+ * region where a gradient is transparent (`glow` fades to transparent at 70%),
+ * so the scrim ends up over the light theme's white page. `ink-on-scrim`
+ * (#f0efed) over that blend:
+ *
+ *   0.60 -> 4.30:1   fails AA
+ *   0.70 -> 6.18:1   passes, with room
+ *
+ * It shipped at 0.60, which is why light-theme scrimmed text was unreadable.
+ * The figure is asserted in the token suite against the white underlay, so a
+ * future nudge downward fails the build rather than the eye.
+ */
+export const SCRIM_OPACITY = 0.7;
+
+/** Lightness deltas applied to an anchor to produce interaction states. */
+export const STATE_DELTA = {
+  /**
+   * Hover on a warm fill goes *lighter*, never darker. The label on a warm fill
+   * is near-black (aesthetic direction §3), so darkening the fill would reduce
+   * label contrast — the opposite of what a hover state should do.
+   */
+  bright: 0.055,
+  /** Pressed/active. Contrast against the near-black label is asserted, not assumed. */
+  dim: -0.045,
+} as const;
+
+/**
+ * Tinted surfaces. These are chosen by eye within a tolerance — a chip
+ * background has no contrast requirement of its own, only a separation one.
+ */
+export const TINT = {
+  /** Accent surface on a dark ground — a dark, low-chroma wash of the hue. */
+  surfaceDark: { l: 0.265, chromaFraction: 0.45 },
+  /** Accent surface on a light ground. */
+  surfaceLight: { l: 0.945, chromaFraction: 0.5 },
+  /**
+   * Hover steps for the tinted surfaces.
+   *
+   * An opaque step, not a translucent wash. `bg-` REPLACES a background rather
+   * than layering on it, so hovering an accent-tinted row with a white wash
+   * swapped the tint out entirely and the row went gray — the opposite of
+   * deepening. Only an opaque step in the same hue can do this.
+   */
+  surfaceDarkHover: { l: 0.325, chromaFraction: 0.45 },
+  surfaceLightHover: { l: 0.905, chromaFraction: 0.5 },
+} as const;
+
+/**
+ * Boundary chroma. Borders are *solved* for 3:1 rather than assigned a
+ * lightness: a hand-picked L that happens to work for orange fails for teal,
+ * which is exactly what the first build run demonstrated.
+ */
+export const BORDER_CHROMA = {
+  onDark: 0.55,
+  onLight: 0.8,
+} as const;
+
+/**
+ * Contrast targets solved at build time. `textOnLight` is the reason this whole
+ * derivation exists: every brand accent fails 4.5:1 as text on white, so the
+ * light theme needs a darkened step per accent, and it must be the *lightest*
+ * step that passes — anything darker throws away brand vividness for nothing.
+ */
+/**
+ * Every solve targets the WORST surface in its theme, never a convenient one.
+ *
+ * Solving light-theme values against pure white and dark-theme values against
+ * the page ground is the most common way a token system passes its own tests
+ * and still fails in the browser: the popover is neutral-900, not neutral-1000,
+ * and the page ground is neutral-50, not white. A value solved to exactly 4.5:1
+ * on white reads 4.35:1 on the actual page.
+ */
+/**
+ * Headroom added to every solve target.
+ *
+ * The solver returns the most vivid step that *just* clears its target, which
+ * ships values sitting at exactly 3.00:1 and 4.50:1 — mathematically correct and
+ * operationally fragile, since any later nudge to a surface or a ramp step turns
+ * a pass into a violation with no warning. Solving to 3.06 / 4.56 costs a
+ * difference no eye can see and buys a margin every future change can spend.
+ *
+ * Assertions still test against the real WCAG numbers, not the padded ones —
+ * the margin is headroom, not a redefinition of the requirement.
+ */
+export const SOLVE_MARGIN = 0.06;
+
+export const SOLVE = {
+  textOnLight: { target: 4.5, against: 'neutral.50 (darkest light surface)' },
+  textOnDark: { target: 4.5, against: 'neutral.900 (lightest dark surface)' },
+  /** Non-text marks — chart series, icons, boundaries — need 3:1 (WCAG 1.4.11). */
+  markOnLight: { target: 3, against: 'neutral.50 (darkest light surface)' },
+  /**
+   * Status text is solved to the AAA house standard rather than the AA floor.
+   * A value solved to exactly 4.5:1 is minimum-legible by construction, and it
+   * showed: every hue came out muddy on the first build.
+   */
+  statusText: { target: 7 },
+} as const;

package/src/primitives/elevation.ts

@@ -0,0 +1,38 @@
+/**
+ * Halogen — elevation primitives.
+ *
+ * Depth comes from surface contrast, not shadow. Levels 0-2 carry no shadow at
+ * all; only floating surfaces get one, and there are exactly three shadow
+ * values.
+ *
+ * In dark mode a shadow on a near-black ground is close to invisible, so
+ * `elev-3` and `elev-4` substitute a 1px top highlight — light appearing to
+ * catch the top edge. Same intent, actually visible. That substitution is
+ * expressed in the semantic layer, not here.
+ */
+
+/** Alpha values used for hairlines, highlights and scrims. */
+export const alpha = {
+  /** Hairline border on a dark ground (white over near-black). */
+  hairlineDark: 0.08,
+  /** Hairline border on a light ground (black over white). */
+  hairlineLight: 0.08,
+  /** The dark-mode elevation highlight that replaces a shadow. */
+  edgeHighlight: 0.06,
+  /** Modal scrim. Flat tint, no backdrop-filter, ever. */
+  scrimDark: 0.72,
+  scrimLight: 0.48,
+  /** Disabled content. */
+  disabled: 0.38,
+} as const;
+
+/**
+ * Three shadows. Each is one ambient layer plus at most one contact layer.
+ * Soft, diffuse, low-contrast — never a color, never stacked, never decorative.
+ */
+export const shadow = {
+  sm: '0 1px 2px 0 rgb(0 0 0 / 0.16)',
+  md: '0 4px 12px -2px rgb(0 0 0 / 0.24), 0 2px 4px -2px rgb(0 0 0 / 0.16)',
+  lg: '0 16px 40px -8px rgb(0 0 0 / 0.36), 0 4px 8px -4px rgb(0 0 0 / 0.2)',
+  none: 'none',
+} as const;

package/src/primitives/motion.ts

@@ -0,0 +1,129 @@
+/**
+ * Halogen — motion primitives.
+ *
+ * Reduced-motion handling lives in the generated CSS, not here: transforms are
+ * zeroed but opacity fades are retained at `fast`, because removing state-change
+ * feedback entirely makes changes harder to perceive for the people the
+ * preference exists to serve (aesthetic direction §17).
+ */
+
+export const duration = {
+  instant: '0ms',
+  /**
+   * Press-down only.
+   *
+   * Deliberately faster than `fast`. A press is the one moment where the
+   * interface is responding to a finger already on the control — anything at or
+   * above 100ms reads as lag rather than feedback, because the user's own motion
+   * has already finished.
+   */
+  press: '70ms',
+  fast: '120ms',
+  base: '180ms',
+  slow: '260ms',
+  slower: '400ms',
+  /** Page and hero transitions only. */
+  deliberate: '600ms',
+} as const;
+
+/**
+ * Choosing a curve: is the journey the point, or the arrival?
+ *
+ * `ease-enter` is easeOutQuart and is violently front-loaded — roughly 40% of
+ * the way in the first 15% of the duration. That is exactly right for something
+ * *arriving*, where the eye should register the end state and not the travel.
+ *
+ * It is wrong for anything whose motion is the point. Three separate effects in
+ * this system were built on it and read as instant despite animating correctly:
+ * the icon reel, the input's focus fade, and an early hover treatment. In every
+ * case the fix was the same — `ease-move`, which is symmetric and spends the
+ * duration on the journey.
+ *
+ * The rule: if a person is meant to SEE the motion, use `move`. If they are
+ * meant to see the result, use `enter`.
+ */
+export const easing = {
+  /** Appear / expand. The default for arrival. */
+  enter: 'cubic-bezier(0.22, 1, 0.36, 1)',
+  /** Dismiss / collapse. */
+  exit: 'cubic-bezier(0.64, 0, 0.78, 0)',
+  /** Reposition / morph. */
+  move: 'cubic-bezier(0.65, 0, 0.35, 1)',
+  /** Gentle overshoot, <= 4%. Selection, toggle and success only. */
+  overshoot: 'cubic-bezier(0.34, 1.4, 0.64, 1)',
+  linear: 'linear',
+} as const;
+
+/**
+ * The press interaction.
+ *
+ * 3% is the whole effect: enough to read as a physical push at 32px, small
+ * enough that a 56px marketing CTA does not appear to jump. Scale rather than
+ * translate, because a fixed offset that feels right on a small control looks
+ * like a glitch on a large one.
+ *
+ * The timing is asymmetric, and inverted from the system's usual "enter fast,
+ * exit faster" rule: the press goes down in `duration-press` (70ms) and returns
+ * over `duration-fast` (120ms). That inversion is what makes a button feel
+ * sprung rather than mushy — instant commitment, relaxed release. The general
+ * rule is about elements arriving and leaving; this is a surface responding to
+ * touch, and it wants the opposite shape.
+ *
+ * No overshoot. The aesthetic direction reserves `ease-overshoot` for selection,
+ * toggle and success, and explicitly rejects bounce — a button that springs past
+ * its resting size reads as a toy.
+ */
+export const press = {
+  scale: '0.97',
+} as const;
+
+/**
+ * The icon reel — a slot-machine swap on hover.
+ *
+ * Two copies of the glyph stacked in an overflow-hidden window; on hover the
+ * pair travels one window height, so the resting icon leaves upward as its twin
+ * arrives from below. Travel is a percentage rather than a length so the effect
+ * is correct at every icon size without a second token.
+ *
+ * Set to 0% under reduced motion, which makes the whole thing inert without the
+ * component needing to know.
+ */
+export const reel = {
+  travel: '100%',
+} as const;
+
+/**
+ * Overlay entrances.
+ *
+ * Overlays are the one place Halogen uses keyframes rather than transitions,
+ * and not by preference: Radix decides when a closed overlay may unmount by
+ * watching `animationName`. A transition is invisible to it, so an exit written
+ * as a transition simply never plays — the element is gone before it starts.
+ *
+ * Each overlay runs TWO animations: opacity on `duration-fade`, transform on a
+ * movement duration. That split is what lets reduced motion neutralise the
+ * travel and the zoom while keeping the fade perceptible, which is the same
+ * rule the press and the spinner follow.
+ *
+ * Reduced motion collapses these to 1ms rather than setting `animation: none`,
+ * so the opacity fade survives while the travel and the zoom do not — the same
+ * rule the press and the spinner follow.
+ *
+ * Not, as first assumed, because `none` would strand a closed overlay in the
+ * DOM. Radix reads `animationName`, treats `none` as "no animation" and
+ * unmounts immediately; the assumption was tested in a browser and disproved.
+ */
+export const overlay = {
+  /** Dialogs settle in from fractionally small. Subtle enough not to read as a bounce. */
+  zoomFrom: '0.96',
+  /** Sheets travel their own full width or height. */
+  sheetTravel: '100%',
+} as const;
+
+/** Maximum travel distance, per aesthetic direction §17. */
+export const travel = {
+  /** Product UI */
+  ui: '8px',
+  /** Marketing surfaces */
+  expressive: '24px',
+} as const;