Skip to content

Paint menu, select and combobox surfaces on the page's own palette - #2

Merged
JArmandoAnaya merged 1 commit into
mainfrom
light-popovers
Sep 1, 2026
Merged

JArmandoAnaya merged 1 commit into
mainfrom
light-popovers

Conversation

@JArmandoAnaya

Copy link
Copy Markdown
Contributor

What changed

menuColor moves from inverted to default, and dropdown-menu, select and combobox are regenerated from the registry so they stay shadcn-canonical.

Under inverted, DropdownMenuContent, DropdownMenuSubContent, SelectContent and ComboboxContent each carried the literal dark class. A floating surface was therefore the dark theme's popover regardless of the page beneath it. That was deliberate and documented — "contrast on purpose" — but the first light application to open a dropdown gets a black panel that reads as a different product, and the design system ends up disagreeing with itself on the same screen.

The surfaces now follow whatever palette the page is in, light or dark.

The tooltip is untouched. Nova paints it bg-foreground text-background, which flips by construction: one line of text has no palette of its own to keep in step.

Why regenerate rather than edit

dark lives in the committed canonical snapshots, and gates/canonical.test.mjs permits added lines only — a hand-edit fails it. menuColor is a first-class preset field, so flipping it and re-running pnpm shadcn:add dropdown-menu select combobox updates both the snapshot and the primitive together, and the gate keeps comparing like for like. The only delta the script re-applies on top is the import relativisation.

shadcn/select.tsx also picks up a "use client" directive the CLI now emits. It is inert in this build and lands in both snapshot and primitive, so it does not open a gap in the gate.

Design record

DESIGN.md §"Menus and the inverted subtree" becomes §"Menus and the page's palette" and states the new rule; the preset table row and the menuColor assertion in gates/tokens.test.mjs move with it. The rule and its gate move together or not at all, per the file's own convention.

Consequences

Every menu, select and combobox in every consuming application changes appearance, VisionSet included. This is a visual change, not a behavioural one: no props, exports or class-name contracts move.

Released as 0.1.1; publishing needs the v0.1.1 tag after merge.

Found, not fixed

Nothing.

Test plan

  • pnpm test:gates — 51 pass, 0 fail, including the three canonical-snapshot gates and the config gate
  • pnpm test — 7 files, 61 tests pass
  • pnpm lint — clean (eslint + tsc --noEmit)
  • pnpm build — clean
  • Verified in the Robomous Cloud console against a live signed-in session: the user menu renders on the page's palette.

`menuColor: inverted` gave every floating surface the literal `dark` class,
so a menu was the dark theme's `popover` whatever the page was doing. In a
light application the panel arrives as a black rectangle that reads as a
different product, and the first consumer to open a dropdown on a light page
sees the design system disagree with itself.

The preset flag moves to `default` and the three affected primitives are
regenerated from the registry, so they stay shadcn-canonical and the additive
gate keeps comparing like for like. The tooltip is untouched: Nova paints it
`bg-foreground text-background`, which flips by construction.

DESIGN.md records the new rule in place of the old one, and the config gate
moves with it.
@JArmandoAnaya
JArmandoAnaya merged commit ad431ad into main Sep 1, 2026
1 check passed
@JArmandoAnaya
JArmandoAnaya deleted the light-popovers branch September 1, 2026 18:51
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