enricobuehler
d97a7aea18
Three defects, all of the same shape: a token that happens to look right on THIS
library's own palette and wrong on a consumer's.
Select trigger
- `border-main` and `focus-visible:ring-main/50` resolve to --main, which is the
FOREGROUND. On the Punktfunk console theme that is a near-white border and a 3px
near-white focus ring — reported from the field as "a really bright outline".
- `data-placeholder:text-secondary` and the chevron's `text-secondary`: --secondary is
a SURFACE colour there, so the chevron and placeholder were painted in a background
tone at 50% opacity and all but vanished. That is what made the control stop reading
as a select at all.
- Retuned to InputText's vocabulary — border-input, ring-ring at ring-1, rounded-md,
px-3 — because a select sits beside text inputs in every form we ship and the two
must not look like different widgets. The chevron now carries its own colour and no
opacity knock-down.
InputNumber
- The spinner arrows are drawn by the BROWSER. With no declared color-scheme the UA
paints them for a light UI: near-black arrows on a near-black field, i.e. invisible.
Declared via arbitrary properties rather than Tailwind's scheme-* so it holds
whatever Tailwind version a consumer builds with.
Why none of this was caught here: src/styles/theme.css has NO dark palette — 134 lines,
zero dark tokens — so every story in this Storybook renders light, and all three failures
need a dark consumer palette to appear. Components already use `dark:` variants for a
palette this workbench cannot show. Worth fixing separately; it is the actual root cause.
Also adds the stories these three never had (Select, InputNumber, InputText). form/Select
→ "In a form row" and form/InputText → "With a button" are the ones that make a height or
ring mismatch obvious on sight.