Skip to content
GitHub
Sections

Reference · Components and layout

Choosing an input control

This is a spec: descriptive guidance, not a checkable rule. It carries no forbidden and instead pair, and no jig check detector applies to it directly.

The spec

The control determines the interaction cost before a single pixel is styled. Choose by the shape of the answer, not by what fits.

The answer is…UseNot
One of ~10 or fewer optionsRadio buttons, stacked verticallyA dropdown
One of a long known list (country, product)AutocompleteA long dropdown
One of a long list the user must browseTwo dependent fields (industry → occupation)One enormous dropdown
A small number, changed in small stepsStepperA dropdown or free number field
A large or arbitrary numberText input with inputmode="numeric"A stepper
On or off, applied on submitCheckboxA toggle
On or off, applied immediatelyToggle switchA checkbox
Several of a setCheckboxes, stacked verticallyA multi-select dropdown

Why dropdowns lose so often: they cost open, scroll, choose — several precise interactions, punishing with a motor impairment. They look filled when empty, so they get skipped. And their options are hidden, so they cannot be scanned or compared. Use one when space genuinely matters.

Radio buttons and checkboxes stack vertically. A horizontal row makes it easy to hit the wrong one and harder to see which label belongs to which control.

Autocomplete: keep suggestions to about ten to avoid choice paralysis, and bold the differing part of each suggestion so they can be told apart at a glance. Suitable when people know what they are looking for; not when they need to browse to decide.

Steppers: + and −, not up/down arrows or chevrons — arrows read as a dropdown or accordion. Lay the buttons out horizontally, so there is space between them and less chance of hitting the wrong one. Each button gets --size-touch-target. Not for large changes.

Checkbox vs toggle is about *when the change applies*, not about looks. A checkbox waits for submit; a toggle takes effect immediately. Label each with what happens when it is on.

Positive phrasing (F-103): test a checkbox label by putting "Yes," in front of it. "Yes, allow automatic updates" works. "Yes, don't allow automatic updates" does not.

Kind
Spec
Section
Components and layout

Read as plain text