swarm-ui: equal-width create-agent cards, full-width inputs

mara's follow-up: both cards should be the same size (flex: 1 1 0
instead of the form keeping its own narrower basis), and the form's
inputs should fill the card rather than stopping at their old 16em
cap. Dropped that cap from the shared form kit (.ui-form-control /
.ui-form-field) entirely rather than overriding it per-page — the kit
itself has no width opinion now, same as Panel already has none; a
page that wants a narrower field caps its layout, not the kit.

Checked ComponentsPage's standalone samples (no regression, just
wider) and narrow-viewport stacking (still moves the explanation
under the form).
This commit is contained in:
iris 2026-08-19 14:48:00 +02:00 committed by mara
commit 3b339b2232
2 changed files with 38 additions and 31 deletions

View file

@ -1,31 +1,34 @@
/* <FormField> label stacked above its control, plus the shared
`.ui-form-control` chrome every text/select input in the kit draws
from (one class, so the two never drift). `max-width` + `width: 100%`
rather than a fixed `width`: caps the control on a wide desktop
viewport without forcing an overflow on a narrow/touch one.
`min-height` is a touch-target floor (44px at the default 16px root
font WCAG 2.5.5's minimum), not a visual choice — it's the same on
every control in the kit whether or not it's ever used on a touch
device, since the alternative is a component that behaves differently
per input method. Colours are the shared base16-derived vars
from (one class, so the two never drift). `width: 100%` fills
whichever container the caller gives it the kit itself has no
opinion on a maximum width; a page that wants one narrower than its
own layout caps it at the layout level (`CreateAgentPage.css`'s
`.create-agent-form-col` is the existing example), same reasoning
`Panel` has no width opinion of its own either. `min-height` is a
touch-target floor (44px at the default 16px root font WCAG
2.5.5's minimum), not a visual choice — it's the same on every
control in the kit whether or not it's ever used on a touch device,
since the alternative is a component that behaves differently per
input method. Colours are the shared base16-derived vars
(../../theme.css), never literal.
The field wrapper repeats `.ui-form-control`'s own `width: 100%;
max-width: 16em` rather than leaving the wrapper unconstrained: inside
a shrink-to-fit flex column (`CreateAgentPage`'s form is one), an
unconstrained wrapper sizes to its own content and a `width: 100%`
*control* inside an auto-width wrapper resolves against that shrunk
width, not the intended 16em cap, so two fields with differently-long
labels ("agent name" vs "hive") ended up with differently-wide inputs
the misalignment mara reported on the create-agent page. Matching the
two declarations here means every field's control width is driven by
the same fixed cap regardless of its label's length or its siblings'. */
The field wrapper repeats `.ui-form-control`'s own `width: 100%`
rather than leaving the wrapper unconstrained: inside a shrink-to-fit
flex column (`CreateAgentPage`'s form is one), an unconstrained
wrapper sizes to its own content and a `width: 100%` *control*
inside an auto-width wrapper resolves against that shrunk width, not
the container the page actually gave it, so two fields with
differently-long labels ("agent name" vs "hive") ended up with
differently-wide inputs the misalignment mara reported on the
create-agent page. Matching the two declarations here means every
field's control width is driven by the same container width
regardless of its label's length or its siblings'. */
.ui-form-field {
display: flex;
flex-direction: column;
gap: 0.3em;
width: 100%;
max-width: 16em;
}
.ui-form-field-label {
font-size: 0.85em;
@ -39,7 +42,6 @@
padding: 0.4em 0.6em;
font: inherit;
width: 100%;
max-width: 16em;
box-sizing: border-box;
min-height: 2.75em;
}