Stickies unreadable in dark mode: un-scoped :root editor color fallback overrides the dark theme ramp

[Liewzheng]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

In dark mode, sticky notes (Stickies page, also sticky comments) render with light pastel backgrounds — e.g. the orange card computes to rgb(255, 227, 205) — while the text stays light (oklch(0.92 …)), making the content unreadable.

Expected: in dark mode the cards should use the dark ramp from [data-theme*="dark"] (orange #583e2a etc.) so the light editor text stays readable.

Screenshots

Before (dark mode, current preview): light card backgrounds with unreadable light text.

After (dark mode, with the fix from the linked PR): dark ramp backgrounds, readable text.

Steps to reproduce

1. Run the current preview branch (observed on self-hosted v1.4.2).
2. Switch to the dark theme.
3. Open the Stickies page and create or view a sticky note.
4. Observe the light background with near-white text.

Root cause analysis

The editor color variables used by stickies (--editor-colors-*-background, consumed via STICKY_COLORS_LIST → inline backgroundColor: var(...)) are defined in two places:

• packages/editor/src/styles/variables.css — :root light defaults first, then [data-theme*="light"] and [data-theme*="dark"] ramps.
• apps/web/styles/globals.css and apps/space/styles/globals.css each keep an un-scoped :root fallback block holding the same light values (intended as a pre-theme fallback).

Within the editor package the :root defaults come before the themed blocks, so the dark ramp wins there. But in the bundled app CSS, the apps' fallback :root blocks are ordered after the editor package's [data-theme*="dark"] rules — and at equal specificity (:root vs attribute selector both matching html) the later rule wins, so the light fallback overrides the dark ramp regardless of theme. Light mode was unaffected only because the fallback values happen to be identical to the light ramp.

Proposed fix

Scope the fallback blocks so they can never override a themed ramp:

:root:not([data-theme*="light"]):not([data-theme*="dark"]) { … }

This keeps the fallback semantics for the pre-theme window and for custom themes (next-themes includes a custom theme that matches neither selector, so deleting the block outright would leave those variables undefined).

Verified on a self-hosted instance rebuilt with the fix: dark mode computes sticky backgrounds to the dark ramp (rgb(88, 62, 42) for orange) with light readable text; light mode is unchanged (rgb(255, 227, 205) + dark text), since the fallback values are value-identical to the [data-theme*="light"] ramp.

I have the fix ready and will open a PR referencing this issue.

Environment

Production / self-hosted (Docker) and local dev on preview branch

Browser

Google Chrome

Version

v1.4.2 / current preview branch