The No/Līdz number-input boxes were sized for a hardcoded 3-column grid
(minmax(250px,1fr)) despite only ever holding 2-3 digit temperatures.
Switched to grid-template-columns: repeat(auto-fit, minmax(165px,1fr)) --
the browser now fits however many 165px+ cards actually fit at the current
width, growing them to fill leftover space, with no manual breakpoints
needed (removed three now-redundant @media overrides for .rangeGrid).
Caught a real bug while tuning the floor value: a naive hardcoded
repeat(6, minmax(130px,1fr)) first pass produced 6 columns at every width
from 1050px to 1900px, but at some widths in that range (e.g. 1300px) the
resulting per-input width came out to ~38px -- native number-input spinner
arrows ate nearly all of it, and the digits, while genuinely present in the
DOM (verified via inputValue()), were visually clipped to nothing. The map
preview below (fed by the same signal) still rendered correctly, which is
what made clear this was a paint/width issue, not a data bug. Fixed two
ways: hid the native spinner arrows (reclaims space, matches the project's
existing pattern of fully custom-styling other native inputs like
checkboxes) and switched to auto-fit so the actual computed column width
can never fall below the safe floor regardless of viewport width -- the
exact class of bug a hand-rolled breakpoint ladder is prone to.
Verified via a programmatic sweep (14 widths from 375px to 1900px, reading
each input's real computed width and value, not just eyeballing
screenshots) that every width keeps at least ~53px per input -- confirmed
by direct visual check to be comfortably legible, well clear of the ~38px
threshold that broke -- and headless-browser screenshots at 1600/1300/700px
confirm all six cards render correctly with real live data.
b0txec
e62895ad68