Editorial Frame: Chrome Tone doesn't visibly change, needs Color Signal alignment

[georgeolaru]

Problem

The Chrome Tone Customizer control (Strong Contrast / Quiet Contrast / Accent) produced no visible change when toggled. Three control choices all resolved to near-black colors in the default Hive palette:

• Strong Contrast → `--sm-current-fg1-color` → `#222222`
• Quiet Contrast → `--sm-current-fg2-color` → `#363636`
• Accent → `--sm-current-accent-color` → `#000000`

The mechanism worked end-to-end (body class, CSS rule, variable substitution all correct), but the palette's accent color happens to be black, so "Accent" is indistinguishable from the contrast tones. The control felt broken.

Separately, the control rendered as a horizontal radio pill that couldn't grow beyond three options.

Fix

Replace the bespoke tone model with the same Color Signal + palette picker Nova Blocks uses, so the chrome inherits the full palette/variation token cascade instead of reinventing a parallel system.

• New options replace `sm_chrome_color_role`:

  • `sm_chrome_palette` — picks a Style Manager palette by ID. Choices are enumerated from `sm_get_saved_palettes()`. Defaults to the site's primary (first) palette.
  • `sm_chrome_signal` — Low / Medium / High. Mapped to palette variation via the default signals array `[1, 3, 8, 11]` (`low` → 3, `medium` → 8, `high` → 11), matching `getSignals()` in `@novablocks/utils`. Defaults to `high`.

• The chrome shell now carries `sm-palette-{id} sm-variation-{N} sm-color-signal-{idx}` classes on the `.c-editorial-frame` wrapper (not on body), scoping the palette + variation context to the chrome subtree so it never leaks into the main content palette.

• `_editorial-frame.scss`:

  • Removed the old `body.has-editorial-frame-tone-*` rules.
  • Moved `--editorial-frame-surface` / `--editorial-frame-ink` / `--editorial-frame-divider-color` onto `.c-editorial-frame` so they resolve inside the palette-scoped context instead of being pre-evaluated at body scope.
  • Surface now points at `var(--sm-current-bg-color)` (the variation's background — what a signalled block would paint) and ink at `var(--sm-current-fg1-color)`, so higher signals translate into more prominent chrome against the page.
  • Added `background: transparent !important` on `.c-editorial-frame` to beat Style Manager's inline `[class*="sm-variation-"]:where(:not(.sm-color-signal-0))` rule that would otherwise paint this full-viewport positioning shell with the variation's background.

• `customizer.scss`: laid `#customize-control-sm_chrome_palette_control` and `#customize-control-sm_chrome_signal_control` out vertically so each option has room for a longer label and we can add more levels later without cramming a single pill row.

Verified

• Customizer shows two vertical radio lists: Chrome Palette (Brand Primary / Color / Info / Error / Warning / Success) and Chrome Color Signal (Low / Medium / High), both with defaults applied.
• Signal switches update the preview:
  • Low → `sm-variation-3`, surface `#ffffff` (subtle, nearly invisible on a light page).
  • Medium → `sm-variation-8`, surface `#4d4308` (dark yellow).
  • High → `sm-variation-11`, surface `#000000` (classic black editorial chrome).
• Palette switch (Brand Primary → Color) changes the resolved bg/fg1 of the chrome bars without affecting the page content palette.
• Page content renders normally; the chrome wrapper stays transparent behind its visible `__top` / `__left` / `__rail` children.

Fixes #451