Comparison library · 8 ambiguity groups
Use side-by-side contracts to separate UI components that look similar but require different focus, keyboard, modality, persistence, placement, or value behavior.
Describe an interfaceChoose the next route
Use a name guide, a side-by-side comparison, or the identification process without forcing one page to answer all three tasks.
Name known
Use the reference library when you know or suspect the name and need a reviewed behavior contract.
Open the component name libraryName unknown
Use the identification guide when you can describe behavior but do not yet know which component or comparison to open.
Open the identification guideCommon comparison decisions
These routes answer existing comparison questions. They do not add new taxonomy terms or create new URLs.
When people search for drawer vs modal, “modal” usually means a Modal Dialog. The deciding requirement is whether the user must finish a focused task before using the page behind it, or needs an edge-entering surface that keeps more context visible.
Open the direct Modal Dialog vs Drawer comparisonA Combobox is the control that combines input or selection with a related popup. Autocomplete is the suggestion behavior that filters or completes values as users type, often inside an editable Combobox.
Open the direct Combobox vs Autocomplete comparisonA Toast reports a recent event without blocking work and may disappear after users have time to perceive it. A Banner keeps a condition or announcement visible while it remains relevant to the page or site.
Open the direct Toast vs Banner comparisonA checkbox represents an independent choice, so several choices may be selected. A Radio Button belongs to a Radio Group, where one visible option replaces the others for a single choice.
Open the direct Checkbox vs Radio Group comparisonComparison method
A useful comparison eliminates the wrong component before it recommends the closest name.
Decide whether the interface communicates information, collects a value, exposes commands, navigates, interrupts a task, or reveals hidden content. Components with a similar outline may solve different jobs.
Write down the trigger, dismissal route, focus movement, keyboard behavior, background availability, placement, persistence, and mobile adaptation. These facts form the implementation contract.
Ask what would break if you used the nearest alternative. If required links cannot be operated, a value cannot be typed, or focus escapes a modal task, the visual match is not enough.
Comparison library
Each file includes a behavior matrix, decisive questions, related pattern definitions, and an implementation-oriented conclusion.
Frequently asked questions
Direct answers based on the reviewed behavior contract above.
Appearance does not reliably determine semantics or behavior. Two surfaces can share the same size and position while requiring different focus, keyboard, dismissal, modality, persistence, or value rules. Comparing contracts exposes those differences before implementation.
Start with the user task and the requirement that would make an alternative fail. Interactive content, background blocking, editable input, command versus navigation intent, message persistence, and single versus grouped disclosure are common decisive boundaries.
No. The comparison is framework-neutral. It helps you specify behavior and reject incompatible patterns. You still select a component library, confirm its actual contract, and test the implementation in your browser and assistive technology setup.