- Job
- Operable controls
- Requirement
- must specify
- States / rules
- default, hover, focus (keyboard, visually distinct), pressed, disabled; error / loading / empty / success where the control takes data. Focus ring is its own row
- Specified means
- Each interactive atom lists these states
- Hardest context
- Keyboard-only on dark
Focus ring 2px offset on dark card
outline: none with no replacement
How this lives in Building Blocks
Representation: Shared foundation / token / behavior guidance.
Building Blocks should provide shared guidance, semantic roles, examples, and reusable implementation hooks where appropriate. Each product maps those roles to its own theme and documents any justified exceptions.
Specify the control over time, not just at rest.
The control is understandable before interaction.
Pointer-only enhancement, never the only cue.
Keyboard location is visually distinct from hover.
Immediate interaction feedback.
Unavailable state remains understandable in context.
Error / loading / empty / success only where the control takes or reports data.
- Keyboard-only on dark
- Focus ring remains visible on a 16px control
- Disabled state does not erase the reason
Do not specify the easy case only.
The source checklist’s hardest-context test is part of what “specified” means: Keyboard-only on dark.
On-spec signal
Focus ring 2px offset on dark card
Failure signal
outline: none with no replacement
Catalog connection
The product-local Catalog should show this row’s actual state for that product using the Catalog contract. Building Blocks documentation can define the baseline, but it does not make a product’s row Specified, Designed, or In code by itself.