Skip to content

fix(theme): solid primary buttons follow the skin, like outline ones already did - #193

Merged
WebTigers merged 1 commit into
mainfrom
fix/btn-primary-follows-skin
Aug 28, 2026
Merged

fix(theme): solid primary buttons follow the skin, like outline ones already did#193
WebTigers merged 1 commit into
mainfrom
fix/btn-primary-follows-skin

Conversation

@WebTigers

Copy link
Copy Markdown
Owner

The bug

A card showing a btn-primary next to a btn-outline-primary drew one Bootstrap blue and one skin orange under Bengal.

Bootstrap 5.3 bakes the stock blue #0d6efd into both variants' component vars, so a skin that swaps --bs-primary restyles neither. default.css already rebound .btn-outline-primary to var(--bs-primary) — with a comment explaining exactly this trap — but .btn-primary was never given the same treatment.

So the outline tracked the skin and the solid didn't, and any pairing of the two disagreed:

skin --bs-primary outline solid (before)
bengal #c65312 orange blue
jaguar #2c3e50 navy blue
tabby #e95420 orange blue
puma #3459e6 blue-ish blue (coincidence — hid it)
cheetah #0d9488 teal teal (own hardcoded rule — hid it)

Two skins accidentally looked correct, which is why it survived.

The fix

Both variants bound to the token, so every skin renders a matching pair.

Hover/active darken via color-mix, each preceded by a plain var() fallback — a browser without color-mix drops the unsupported declaration and keeps the earlier one, so the button degrades to a flat skin-colored hover rather than back to blue.

Also reunites the explanatory comment with the rules it documents: a later .cell-emphasis addition had been inserted between them, leaving the comment sitting above the wrong block.

cheetah.css keeps its bespoke solid override. It's redundant now (same teal, hand-tuned shades) but it is exactly the per-skin escape hatch the comment sanctions, and its shades beat a generic mix.

…already did

A card showing a `btn-primary` next to a `btn-outline-primary` drew one Bootstrap
blue and one skin orange under Bengal.

Bootstrap 5.3 bakes the stock blue (#0d6efd) into BOTH variants' component vars,
so a skin that swaps --bs-primary restyles neither. default.css already rebound
.btn-outline-primary to var(--bs-primary) — with a comment explaining exactly
this trap — but .btn-primary was never given the same treatment, so the outline
tracked the skin and the solid did not. Any pairing of the two disagreed, in
every skin except cheetah (which hardcodes its own solid rule and so looked
fine, hiding the bug).

Both variants are now bound to the token, so bengal orange, jaguar navy and
tabby orange all render a matching pair. Hover/active darken via color-mix, each
preceded by a plain var() fallback: a browser without color-mix drops the
unsupported declaration and keeps the earlier one, so the button degrades to a
flat skin-colored hover rather than to blue.

Also reunites the explanatory comment with the rules it documents — a later
.cell-emphasis addition had been inserted between them, leaving the comment
sitting above the wrong block.

cheetah.css keeps its bespoke solid override: it is now redundant (same teal,
hand-tuned shades) but it is precisely the per-skin escape hatch the comment
sanctions, and its shades are better than a generic mix.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WXgMENcwa4Q8yCJaHpjHpf
@WebTigers
WebTigers merged commit 4c39f95 into main Aug 28, 2026
13 checks passed
@WebTigers
WebTigers deleted the fix/btn-primary-follows-skin branch August 28, 2026 13:49
@WebTigers WebTigers mentioned this pull request Aug 28, 2026
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