formatDimensionInput signed values that had rounded to nothing, so a hair below
zero rendered "-0′ 0″" — wrong, and not something parseDimension round-trips.
The sign is now applied only once the rounded feet/inches are actually nonzero.
That fix wanted the decomposition in one place, which formatCm was duplicating
anyway, so both now share feetAndInches(cm, decimals) — magnitude only, sign
applied by the caller once it knows the result isn't zero.
Doing so incidentally fixed a latent bug in formatCm: it took Math.floor of a
negative total, so -76.2cm rendered "-3′ 6″", which reads as -(3ft+6in) = -42in
rather than the -30in it actually is. Nothing renders a negative dimension today
(formatCm is used for garden sizes), but it was wrong and now isn't.
The dimensionInputMode ternary and its comment were duplicated verbatim between
Inspector and GardenFormModal; it is now a helper in units.ts, where the reason
for it belongs anyway.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
Imperial dimension fields took decimal feet rounded to 0.1 ft, which is 1.2
inches — so of the whole-inch marks in a foot only 0", 6" and 12" were exactly
representable. Everything else was off by up to 0.6". Type 2.58 and the field
redisplayed 2.6: the value stored fine, but what you typed and what you saw
disagreed.
Two things made that read as an oversight rather than a decision. The app
already speaks feet and inches, just not where you edit — formatCm renders
24′ 0″, so the garden card said 24′ 0″ × 24′ 0″ while the dialog beside it said
Width (ft) 24. And cmFromFtIn(feet, inches) has always taken an inches
parameter no caller ever passed.
parseDimension accepts 2' 7", 2′ 7″, 2ft 7in, 2' 7, 31", 2', and a bare 2.5
still meaning 2½ feet, so nothing anyone has typed before now breaks.
formatDimensionInput renders the value back as 2′ 7″, with one decimal inch
(7′ 10.5″) rather than whole inches — 0.1" is about 0.25cm, so what is displayed
stays honest about what is stored. Metric entry is unchanged, decimal meters,
and deliberately does not accept feet syntax.
The sign applies to the whole value. -2' 6" is -(2ft + 6in) = -30", not
-2ft + 6in = -18". The naive implementation attaches the sign to the feet term
and gets -18"; there is a test for exactly that.
The no-op guard had to change shape. It compared the parsed value against
displayFromCm(current), which is what stopped a blur-without-edit from drifting
the value; with compound entry there is no single display number to compare
against, and a numeric tolerance has a nastier failure — a bed dragged on canvas
to an arbitrary cm renders as 2′ 7.9″, and merely tabbing through the field
would snap it to a whole inch. It now compares the field's TEXT against the
string that field renders for the current value, which means "you didn't edit
this" exactly. Typing the same value a different way falls through to the cm
comparison and is still a no-op.
The affected inputs move from type="number", which cannot hold 2' 7", to text.
Imperial gets inputMode="text" because ' and " are on no numeric keypad; metric
keeps inputMode="decimal" since it never needs them. A bare number still means
feet, so the keypad path stays usable on a phone either way — but this wants
checking on an actual phone before it's called settled.
Includes the garden grid field, which #47 moved to dimension scale: leaving it
as a number input beside two compound ones would have been the same
two-scales-one-row confusion #47 removed.
cmFromDisplay is gone; parseDimension is the entry path now and nothing else
called it.
Closes#59
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
steveandClaude Opus 4.8