fix(bulma-ui): color TimeInput's wheels from the color prop

[allxsmith]

Closes #701, by styling the class rather than dropping it.

TimeInput put is-<color> on each time wheel, but no CSS styled it, so the wheels stayed primary whatever color said. _timeinput.scss now has a color loop in the same shape as Switch, Slider and Checkbox. For each color, a wheel with is-<color> re-points its two selection variables:

• timeinput-wheel-selected-bg becomes the color;
• timeinput-wheel-selected-color becomes the color's invert.

No new CSS variables, so the theming lists don't change. What changes on screen:

• The selection band and the selected value take the color: the band's fill, and the value's text in the invert.
• The focus ring now reads the band's variable instead of a hard-coded primary, as Switch, Checkbox and Radio's rings read their active color. It looks the same by default. The one visible difference is for someone who already themed --bulma-timeinput-wheel-selected-bg: their ring now follows it.
• Dark mode: Bulma's dark theme doesn't redefine the color variables, so the band looks the same in both schemes, as the primary band always has. I read that from the built CSS rather than checking it in a browser.

The color TSDoc now mentions the wheels, the TimeInput page gets an inline example, and there's a new InlineColors story, since the existing one only shows the wheels once the popover opens.

Tests:

• Render tests check that the class lands on every inline and popover wheel, with and without a class prefix.
• A styles test compiles the real partial and checks each wheel's computed variables.
• A new case in color-tuple-css.test.mjs checks the shipped CSS has a rule for every color the wheels accept. Removing a rule on purpose fails it.

Also in this PR, after the first review:

• The small-viewport overrides now take effect. The max-width: 768px block in _timeinput.scss set --bestax-* variables that no rule read, so it did nothing. It now registers the --bulma-* names the rules read, the way the defaults do. On screens 768px wide or narrower, the wheels get their intended width, gap and mask, and a TimeInput popover gets its larger corner radius. That's a visible change there, and what the code always meant. A styles test fails on any custom property a small-viewport block sets that nothing reads.
• DateTimeInput's color TSDoc now says it colors the wheels too, since it passes color to the same ones.

Noticed and left alone: DateInput's calendar has the same dead is-<color>. It's a natural follow-up with the same loop.

pnpm all passes locally.

[coderabbitai]

Warning

Review limit reached

Next included review available in 24 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: allxsmith/bestax/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 1f116e65-74ab-4877-a1fa-a60a4a6f52e6

📥 Commits

Reviewing files that changed from the base of the PR and between 9740ee9 and 88bc1bd.

📒 Files selected for processing (12)

• bestax-mcp/data/catalog.json
• bestax-mcp/data/components/DateTimeInput.json
• bestax-mcp/data/components/TimeInput.json
• bulma-ui/src/form/DateTimeInputBase.tsx
• bulma-ui/src/form/TimeInput.stories.tsx
• bulma-ui/src/form/TimeInputBase.tsx
• bulma-ui/src/form/__tests__/TimeInput.styles.test.tsx
• bulma-ui/src/form/__tests__/TimeInput.test.tsx
• bulma-ui/src/scss/form/_timeinput.scss
• docs/docs/api/form/datetime/datetimeinput.md
• docs/docs/api/form/datetime/timeinput.md
• scripts/color-tuple-css.test.mjs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Preview Deployment

Preview URL: https://9bd815cf.bestax.pages.dev

[claude]

Deep review — 0 blocking · 4 advisory

#	Severity	Area	Finding	Location
1	🔵 Advisory	Accessibility	The wheel's :focus-visible ring now takes the chosen color, so warning (hsl(42, 100%, 53%)) lands around 1.7:1 against scheme-main — under SC 1.4.11's 3:1. The old hard-coded primary was already ~2:1, and Switch/Checkbox/Radio color their rings the same way, so this extends an existing shortfall rather than creating one.	bulma-ui/src/scss/form/_timeinput.scss:118
2	🔵 Advisory	Robustness	Pre-existing, disclosed in the PR body: the mobile block writes --bestax-timeinput-wheel-width / -gap / -mask, but every reader is var(--bulma-timeinput-wheel-*). Confirmed in dist/bestax.css — the three mobile overrides resolve to nothing. Left alone here.	bulma-ui/src/scss/form/_timeinput.scss:299
3	🔵 Advisory	API	DateTimeInputBase forwards color into the same TimeWheels (line 566), so its wheels change behavior too, but its own color TSDoc still reads "Bulma color modifier." and no story, docs example or test covers colored wheels under DateTimeInput.	bulma-ui/src/form/DateTimeInputBase.tsx:136
4	🔵 Advisory	Robustness	is-<color> still lands on three siblings with no rule — .timeinput (TimeWheels.tsx:778), .timeinput-wheel-band (:659) and the selected .timeinput-wheel-item (:656). Harmless today because the variables inherit down from .timeinput-wheel, but it is the same dead-modifier shape #701 reported, and the new guard only asks for the .timeinput-wheel compound.	bulma-ui/src/form/_pickerInternals/TimeWheels.tsx:658

Overall: The change is sound and the mechanism is the right one — .timeinput-wheel.is-<color> re-points two registered variables, and the band, the selected value and the ring all already read them, so no new selectors or CSS variables were needed. I built the package and confirmed the six rules ship in both dist/bestax.css and dist/versions/bestax-prefixed.css with the correct bestax- class prefix and the unchanged --bulma- variable prefix, that all six --bulma-<color>-invert variables exist, and that the dark theme redefines none of the color lightnesses (one --bulma-primary-l: in the whole sheet), which is what the PR body claims. The riskiest part is the focus-ring switch from a constant to a themeable variable — it is the one thing a consumer can observe change without opting in — and row 1 is where a human should look first.

Residual risk:

• Could a colour still render nothing on the wheels? No. scripts/color-tuple-css.test.mjs reads the union off TimeWheelsProps.color and I replicated the extraction: it yields all six literals, and each is asserted against the shipped sheet. Widening any caller's union without widening TimeWheelsProps is a type error (typecheck:tests passes), so that read is the true narrowest gate, as its comment claims.
• Is the new jest styles test vacuous under jsdom? No. The negative case in the same suite returns an empty string for an uncoloured wheel (jsdom does not inherit custom properties), so the positive cases' var(--bulma-<color>) can only come from a rule matching the wheel element itself.
• Open: Calendar.tsx:191 puts is-<color> on .dateinput, and grepping dist/bestax.css finds only .dateinput.is-small|medium|large — the calendar's color is still dead, exactly as the PR body says. The new guard is wheel-specific, so nothing will catch it; the follow-up needs its own case.
• Open: on mobile, .timeinput-footer-done hard-codes cv.getVar('primary') for both its fill and its own focus ring, so a color="danger" picker shows danger wheels next to a primary confirm button. Invisible to jsdom and to the desktop stories.
• Forced colors: _switch.scss, _checkbox.scss and _radio.scss each pin outline-color: Highlight under @media (forced-colors: active); _timeinput.scss has no such block. Unchanged by this PR — the ring was equally unpinned when it was primary.

🏄 Clean little set wave, brah — the class was already paddling out, this just gave it a board. Rules ship in both builds, tests actually bite, nothing gnarly lurking under the lip. Good to go.

[allxsmith]

deep-review: fresh

Two commits landed after the first review, answering its advisories: 74889d0 makes the small-viewport block register the --bulma-* variables its rules read (it set --bestax-* names nothing read), with a styles test that fails on an unread override, and 88bc1bd updates DateTimeInput's color TSDoc. The first is new behaviour on narrow screens. This review is of the whole PR as it now stands.

[github-actions]

Preview Deployment

Preview URL: https://ea757955.bestax.pages.dev

[claude]

Deep review — 0 blocking · 6 advisory

#	Severity	Area	Finding	Location
1	🔵 Advisory	API	Three wheel variables are registered and documented as themeable but no var() in the shipped sheet reads any of them: --bulma-timeinput-wheel-bg, --bulma-timeinput-wheel-hover-bg, --bulma-timeinput-wheel-item-height. Same failure class as #701 and as the small-viewport block 74889d0 just fixed, in the same partial. The new guard only inspects max-width media blocks, so it cannot see these.	bulma-ui/src/scss/form/_timeinput.scss:34
2	🔵 Advisory	Accessibility	The wheel's :focus-visible ring now takes the chosen colour, so warning lands around 1.7:1 against scheme-main — under SC 1.4.11's 3:1. The old hard-coded primary was already ~2:1, and Switch/Checkbox/Radio colour their rings the same way, so this extends an existing shortfall rather than creating one.	bulma-ui/src/scss/form/_timeinput.scss:119
3	🔵 Advisory	Robustness	is-<colour> still lands on three siblings with no rule — .timeinput (TimeWheels.tsx:778), .timeinput-wheel-band (:659) and the selected .timeinput-wheel-item (:656). Harmless today because the variables inherit down from .timeinput-wheel, but it is the same dead-modifier shape #701 reported, and the new guard only asks for the .timeinput-wheel compound.	bulma-ui/src/form/_pickerInternals/TimeWheels.tsx:658
4	🔵 Advisory	Coverage	DateTimeInput's TSDoc now promises coloured wheels, but nothing exercises it — no story, no docs example, no test. The now-live small-viewport block also widens DateTimeInput's wheels, since they share the .timeinput root, which the PR body describes only in TimeInput terms.	bulma-ui/src/form/DateTimeInputBase.tsx:136
5	🔵 Advisory	Robustness	On small viewports the confirm button hard-codes primary for both its fill and its own focus ring, so a color="danger" picker shows danger wheels next to a primary check. Invisible to jsdom and to the desktop stories.	bulma-ui/src/scss/form/_timeinput.scss:388
6	🔵 Advisory	Robustness	The new guard asks whether a name appears in a var() anywhere in the sheet, not whether the reader sits inside the subtree of the element that sets it, and it matches on max-width only. An override set on the wrong element, or a small-viewport block expressed as min-width, would still pass.	bulma-ui/src/form/__tests__/TimeInput.styles.test.tsx:98

Overall: Both fixes are sound, and I verified them end to end rather than by reading. The colour loop re-points two already-registered variables that the band, the selected value and the ring all read, so it needed no new selectors and no new CSS variables; the small-viewport commit swaps four raw --bestax-* writes for cv.register-vars/cv.register-var, and the built sheet now carries --bulma-timeinput-wheel-width:4rem, -gap, -mask and --bulma-picker-popover-radius:calc(var(--bulma-radius-large) * 4) in both the default and the bestax--prefixed builds, after their defaults in source order so the cascade lands. The riskiest part is that the small-viewport block is new behaviour nobody has looked at — the mask widens its transparent band from 18%/82% to 28%/72%, and the desktop default's own comment warns to keep that band thin so the fade and the mask do not compound; one look in a narrow window settles it. After that, row 1 is where a human should go first.

Residual risk:

• Can the "override registered under a name nothing reads" shape still exist elsewhere? Refuted for the source tree: grep -rn -- "--bestax-" bulma-ui/src/scss/ returns nothing, and no partial writes a --bulma-* or interpolated custom property outside cv.getVar / cv.register-var / cv.register-vars. The four in _timeinput.scss were the only ones.
• Is the new guard actually seeing all four, or silently skipping the :has() rule? Refuted empirically. I ran the same collection over the compiled partial under jsdom 26 / rrweb-cssom and it returns exactly --bulma-timeinput-wheel-width, -gap, -mask and --bulma-picker-popover-radius — .picker-popover:has(.timeinput-panel) parses and its property is collected. Against the pre-fix partial those four read --bestax-*, none of which appear in a var() in bestax.scss, so the test bites rather than passing vacuously.
• Do the now-live overrides win the cascade? Refuted. In dist/bestax.css the default --bulma-timeinput-wheel-width:3rem sits at byte 809307 and the override 4rem at 813519; the popover's default radius at 798204 and the :has() override at 814037 — later in source order, and :has(.timeinput-panel) is 0-2-0 against 0-1-0 besides.
• Do the wider wheels overflow DateTimeInput's floating time card? Refuted. .timeinput-wheel sets overflow: hidden, so its automatic minimum size is 0 and it shrinks as a flex item; a 12-hour-plus-seconds DateTimeInput inside a max-width: 100% time card narrows its wheels instead of spilling.
• Can a colour the wheels accept still render nothing? Refuted. scripts/color-tuple-css.test.mjs reads the union off TimeWheelsProps.color — the narrowest gate, since every feeder must pass a value that type admits — and asserts each of the six against the built sheet; all seven cases pass after a build.
• Open, row 1: --bulma-timeinput-wheel-bg, -hover-bg and -item-height are declared in the built sheet and read by nothing, while timeinput.md:1075-1080, datetimeinput.md:948-953 and skills/bestax-theming/references/css-variables.md:381-384 all advertise them. A consumer who sets one sees no change.
• Open: Calendar.tsx:191 puts is-<colour> on .dateinput and dist/bestax.css ships only .dateinput.is-small, .is-medium and .is-large, so the calendar's color is still dead — exactly as the PR body says. The new node test is wheel-specific, so nothing will catch it.

Gates I ran green: build, TimeInput plus DateTimeInput jest (178), TimeInput.styles.test.tsx (8), node --test scripts/color-tuple-css.test.mjs (7), check:conformance (all 20), gen:mcp:check, gen:catalog:check, typecheck:tests, format:check.

🏄 Two clean rides on one wave, dude — the colour loop was already a glassy little set, and the second commit bailed out four overrides that had been paddling with no board for who knows how long. Nothing gnarly in the water; just peek at that mask on a narrow screen before you call it a day.

[allxsmith]

On the fresh review's advisories:

• Worth a look before merging: the small-viewport block is live now for the first time. Its mask widens the transparent band from 18%/82% to 28%/72%, and the desktop default's comment warns about the fade and the mask compounding. A narrow browser window (768px or less) with the TimeInput stories open settles whether it reads right. If it doesn't, the mask values are the thing to tune.

• Leaving for a follow-up:

  • The three registered wheel variables nothing reads (1).
  • The is-<color> on the wheel's siblings (3), harmless because the variables inherit.
  • The small-viewport confirm button's hard-coded primary (5).
  • The guard's reach (6).

  All four predate this PR or sit beside it, and pulling them in keeps the review from converging.

• Consistent with the rest: the focus-ring contrast (2) follows Switch, Checkbox and Radio.

• Coverage (4): DateTimeInput passes color to the same wheels TimeInput's tests cover, so its TSDoc is accurate. A DateTimeInput story with a color would help, and can come with the calendar color follow-up.

[github-actions]

📸 Story screenshots at handoff — 88bc1bd

6 stories (light + dark) from this PR's changed files under bulma-ui/src/ (workflow run · artifact story-screenshots-pr-832, 30-day retention).

form-timeinput--default · Form/TimeInput · Default

Light	Dark

form-timeinput--controlled · Form/TimeInput · Controlled

Light	Dark

form-timeinput--sizes · Form/TimeInput · Sizes

Light	Dark

form-timeinput--format-12-h · Form/TimeInput · Format 12 H

Light	Dark

form-timeinput--with-seconds · Form/TimeInput · With Seconds

Light	Dark

form-timeinput--increment-steps · Form/TimeInput · Increment Steps

Light	Dark

> ✂ 34 more matched stories skipped by the cap: `form-timeinput--min-max`, `form-timeinput--unselectable-times`, `form-timeinput--inline`, `form-timeinput--audio-tick`, `form-timeinput--manual-entry`, `form-timeinput--manual-entry-12-h`, `form-timeinput--manual-entry-with-seconds`, `form-timeinput--manual-entry-controlled`, `form-timeinput--manual-entry-free-form`, `form-timeinput--manual-entry-12-h-with-seconds`, … — full set in the artifact.

[bestax-release-bot]

🎉 This PR is included in version 5.18.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 2.24.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 1.13.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[bestax-release-bot]

🎉 This PR is included in version 4.2.13 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀