Variant naming matrix
Type: Comparative view
Status: Active derived view
Canonical for: The controlled public Button-property sample across mature design systems
Depends on: Linked first-party component documentation; interpretation follows the reconciliation
This is a controlled Button sample. “Meaning” describes the dominant documented dimension, not an assumed dictionary meaning.
| System | Public property / mechanism | Values sampled | Dominant documented meaning | Mixing or separation | Source |
|---|---|---|---|---|---|
| IBM Carbon | kind | primary, secondary, tertiary, danger, ghost | hierarchy + consequence + appearance | mixed | usage |
| Atlassian | appearance | default, primary, subtle, warning, danger, discovery, rovo | prominence + consequence + experience identity | highly mixed | Button |
| Microsoft Fluent 2 | appearance | primary, secondary, outline, subtle, transparent | prominence and visual treatment | mixed; prose supplies hierarchy | React Button usage |
| Adobe Spectrum WC | variant; treatment; static-color | accent/primary/secondary/negative; fill/outline; black/white | emphasis/consequence; treatment; context color | partially separated | Button |
| React Spectrum | variant; style | accent/primary/secondary/negative; fill/outline | visual style/emphasis; treatment | partially separated | Button |
| GitLab Pajamas | category; variant; state props | primary/secondary/tertiary; default/confirm/danger/link | visual emphasis; action meaning; state | substantially separated | Button |
| Shopify Polaris WC | variant; tone; color | component-dependent; critical/success/info; subdued/strong | rendering; semantic color group; intensity | separated dimensions | web components |
| GitHub Primer | variant | default, primary, danger, invisible, link | visual style with hierarchy/consequence | mixed | Button |
| Material Web | separate component types | filled, filled-tonal, outlined, elevated, text | appearance with documented emphasis | type split; usage in prose | Button |
| GOV.UK | CSS modifiers | secondary, warning, inverse | hierarchy; consequence; context | mixed modifier namespace | Button |
| USWDS | CSS modifiers | secondary, accent-cool/warm, base, outline, inverse, big, unstyled | color, appearance, context, size | mixed modifier namespace | Button |
| PatternFly | variants/types | primary, secondary, tertiary, danger, link, icon, CTA, progress | hierarchy + consequence + form/behavior | mixed | guidelines |
| Salesforce Lightning | variant | neutral, base, brand, brand-outline, destructive, destructive-text, inverse, success | brand/color + treatment + consequence + context | highly mixed | lightning-button |
| Base Web | kind | primary, secondary, tertiary, minimal | action hierarchy | single relative axis | Button |
| Radix Themes | variant; color; highContrast; loading | classic, solid, soft, surface, outline, ghost | appearance; color; contrast; state | cleanly separated, little intent | Button |
Observed patterns
- Documented:
variant,kindandappearancedo not have stable cross-system meanings. - Documented: some systems use appearance labels and attach use guidance in prose; others put consequence terms beside hierarchy terms in the same enum.
- Demonstrated: GitLab, Spectrum, Shopify and Radix show that orthogonal axes can be represented separately in public APIs.
- Not established: public documentation does not show that any of these architectures produces higher LLM selection accuracy.
Beyond Button sample
Feedback components commonly use info, success, warning, critical and neutral, usually as status/tone rather than hierarchy. Selection components expose states (selected, checked, disabled) that are closer to stable platform semantics. Surfaces use appearance/context words such as raised, elevated, subtle and inverse. The recurrence of the same words in different dimensions confirms that the issue is broader than Button, but Button remains the cleanest controlled comparison.