Skip to content

fix(agent-preset): make the preset picker readable in both colour modes - #382

Open
Kunstderfug wants to merge 1 commit into
dataelement:mainfrom
Kunstderfug:fix/agent-preset-colors
Open

Kunstderfug wants to merge 1 commit into
dataelement:mainfrom
Kunstderfug:fix/agent-preset-colors

Conversation

@Kunstderfug

Copy link
Copy Markdown

What

Two colour-mode problems in the agent-preset picker.

1. The preset chip had no border at all (border:none), so sitting beside the workspace picker it read as a stray label rather than a control. It now carries a 1px --dsw-alias-state-business-primary ring, with the horizontal padding trimmed from 8px to 7px so the ring is paid for out of the existing box: the chip neither grows nor shifts against its neighbours. The label stays --dsw-alias-label-primary in both modes, so the mode is carried by the ring rather than by coloured type.

2. The "Browse Awesome Presets…" footer was the one row in that menu painted accent blue, and it used a fixed, dark-mode-blind #3154df over a translucent accent tint. Contrast against the row's own painted background:

surface before (#3154df) after
dark menu rgb(30,33,45) 2.50:1 5.10:1
light menu #e6e6e6 4.60:1 4.50:1
white 5.68:1 5.57:1

2.50:1 is well under the 4.5:1 AA floor for body text and reads exactly as the "blue text on dark background" bug. The row now resolves per colour mode (#3a58c4 light, #679efe dark) with the hover tint following each.

Disclosure: the replacement light blue is marginally lighter than the old one, so the light-theme cases lose a little margin (4.60 → 4.50 on the #e6e6e6 menu, i.e. exactly on the floor). Dark mode goes from broken to comfortable. Darkening the light value is a one-value change if you want margin there.

Why body[data-ds-dark-theme] and not light-dark()

I reached for light-dark() first. It is supported in the bundled Chromium, but the app never declares color-scheme (computed value normal), so light-dark() silently resolves to its light branch while the dark theme is active — a fix that changes nothing on screen. The override therefore keys off body[data-ds-dark-theme], the mechanism the rest of the app already uses. The test asserts both that the attribute selector is present and that light-dark( is absent.

Verification

  • Live in the running app: computed style on the chip is border: 1px solid rgb(103, 158, 254) with padding: 0px 7px, and the injected stylesheet carries the new body[data-ds-dark-theme] .YgMYBq_awesome rules.
  • The patch applies to the pristine published 0.1.2-rc.1 client bundle and reproduces the installed client.js byte-for-byte (f2a3279e…).
  • npx vitest run test/agent-preset-chip.test.ts — 8 passed on this branch alone. It does real WCAG relative-luminance and compositing math for both modes, and keeps the old #3154df as an explicit failing floor rather than a passing number.
  • npm test — 810 passed / 95 files. npm run typecheck clean.

The preset chip sat beside the workspace picker with no border at all, so
it read as a stray label rather than a control. It now carries a 1px
state-business ring, paid for out of the old horizontal padding (8px to
7px) so the chip keeps its width and stays aligned with its neighbours.

The "Browse Awesome Presets..." footer was the one row in that menu
painted in accent blue, using a fixed #3154df over a translucent accent
tint. On the dark-theme menu surface that measures 2.64:1 -- visibly
wrong blue-on-dark, and far below the 4.5:1 floor for body text. The row
now takes a blue per colour mode: #3a58c4 in light, #679efe in dark
(5.10:1), with the hover tints following each.

The dark override keys off body[data-ds-dark-theme] rather than
light-dark(): the app never declares color-scheme, so light-dark() would
silently resolve to its light branch while the dark theme is active.

The test computes WCAG contrast for both modes, keeps the old #3154df as
an explicit failing floor, and pins the ring plus the absence of
light-dark().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant