You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There have been cases where the Button component is used with heavy style overrides. This can lead to subtle bugs and breakages down the line.
Although we should always first reconsider if one of the standard Button style variants can be used instead, in some cases heavy style customization is warranted. While styling a simple button element from scratch may seem like a valid alternative, that may also lead to developers overlooking subtle considerations (focus styles, accessibility, etc) that are already handled in Button.
What is your proposed solution?
We should audit the repo for the kinds of valid style overrides we have, and figure out how Button can support those use cases cleanly. Some possibilities include:
an unstyled variant
providing modular styles (focus styles, hover styles, etc) through something like a useButtonStyles hook
The text was updated successfully, but these errors were encountered:
A useful exercise could be to run through Button's code and, for each "feature", assign it to either "core behavior" or a separate "add on" (ie. styles).
Also, we may want to "merge" the unstyled variant work with the potential refactor from default / primary / secondary / tertiary / link to solid / outline / text proposed here and also related to #63856
What problem does this address?
There have been cases where the
Button
component is used with heavy style overrides. This can lead to subtle bugs and breakages down the line.Although we should always first reconsider if one of the standard Button style variants can be used instead, in some cases heavy style customization is warranted. While styling a simple
button
element from scratch may seem like a valid alternative, that may also lead to developers overlooking subtle considerations (focus styles, accessibility, etc) that are already handled inButton
.What is your proposed solution?
We should audit the repo for the kinds of valid style overrides we have, and figure out how Button can support those use cases cleanly. Some possibilities include:
unstyled
variantuseButtonStyles
hookThe text was updated successfully, but these errors were encountered: