Understanding the use case for text button

[joaomarcelofm]

Hello everyone!

Our team is finding it hard to understand the use case for the text variant of buttons. The main issue is that most of the time, it requires custom styling to prevent the UI from looking misaligned.

For instance, in the sample code:

In the example above, the UI looks buggy and misaligned until the user hovers and sees that some background is applied to the padding. This requires us to apply custom styles to make it look as our designers desire, but generally, how text buttons look everywhere, I think 🤔
Also, even if in the "good" example it looks aligned, then when the user hovers, it'd look strange if we used pl-0 as one of the sides wouldn't have a background. Therefore, we often remove that style as well.

Based on other discussions, this seems to be a common issue. Do you have any guidelines for best practices regarding the usage of this button?

Our team is resorting to the full ban on this button style as the custom styling hampers our ability to upgrade prime easily or introduces unintended bugs in the UI.

I understand the need for extra padding for icon-only buttons, as it increases the touch area for accessibility. Still, it generally requires a custom implementation to make it aligned (i.e., dynamically position the button beyond the box boundaries). This may be less of an issue, but it is also important to think about.

[onursenture]

Hello,

I understand the problems with the screenshots you've provided. However, if you have concerns about this alignment, they are likely due to misusing a text button.

Personally, I wouldn't recommend removing the left padding just to achieve left alignment when the button is not in a hover state. In such cases, you should avoid using a text button. That's why there are numerous variations of the button component available.

For instance, you can try the outlined button or the link button, which already has no padding.

[joaomarcelofm]

Thanks for the response @onursenture!

if you have concerns about this alignment, they are likely due to misusing a text button.

That's precisely what I'm trying to understand. Is it expected that a text button will never be around the edges of a component?

However, the expectation of text buttons not being around edges, and therefore breaking alignment, is also broken in some prime elements. For instance, the dialog element:

This might be a design decision, which is fair. But the alignment of the button also breaks seemingly unintentionally in cases where the test of the dialog header is larger.

In the case above, I'd expect the button to be placed relatively to the box, not the sibling content. That's one of the issues with the current text button.
Also, I'm not saying the text button doesn't have a use case, but there are many cases where the default usage makes the UI looks buggy.

Airbnb has many examples of using text buttons whose content is aligned to the rest of the content instead of its outer padding.

Personally, I wouldn't recommend removing the left padding just to achieve left alignment when the button is not in a hover state.

I totally agree here. We aren't doing it, but as shown in the linked discussion there are folks that may be resorting to it in order to make their UI look aligned.

In such cases, you should avoid using a text button. That's why there are numerous variations of the button component available.
For instance, you can try the outlined button or the link button, which already has no padding.

This isn't a solution for us. The text button is relevant for low emphasis actions and applying a different button style may completely change the meaning of it.

While researching this, I came to two possible solutions:

• Apply negative margins to push the buttons to the correct placement. This is how Airbnb is doing it.

• (Preferred) Apply the hover effect as a pseudo-element and let only the button's content take up box-size space (no padding). This is how Google does it:

It'd be neat if this were a component prop, something like: boxSize: boolean. false would remove the padding and apply the styles as pseudo elements. The first option is already achievable today but requires a lot more custom styling.

* Used Airbnb as an example, as they are a company recognized for following and implementing great design principles.

[onursenture]

We can't say that text buttons should never be used in corners. We also have such uses in our components. The 'perfect square' situation you mentioned should be managed by theming or changing the component structure at the use site rather than altering the button component itself.

I will discuss this with my developer colleagues. Thank you for bringing this issue to our attention and suggesting solutions.

[joaomarcelofm]

Thanks for the response @onursenture, I really appreciate it!

The 'perfect square' situation you mentioned should be managed by theming or changing the component structure at the use site rather than altering the button component itself.

Indeed, that was a divergence from the topic and only somewhat related. I'll play with the theme to see if we can achieve that result.