Button enhancements

[basham]

There's a number of small tweaks that could improve Rivet buttons. I'd like to propose some options and submit some PRs. I'd imagine this would be part of Rivet 2 work.

[basham]

Secondary buttons have a transparent background color. This can result in buttons looking disabled, if they happen to live on top of a non-white (gray) background. This CodePen demos this effect in the second column. The third column applies a white background to the secondary buttons. In discussing with the design community a couple months ago, we couldn't find a compelling reason to need transparent backgrounds on secondary buttons. White backgrounds seems like a good change.

[basham]

Buttons should be adjusted so that they are square when the only visible content is an icon. For example, in the Rivet docs, such a button is 44×40 px. The padding could be adjusted to make it 40×40.

[basham]

There is currently only two button sizes (40px tall and 24px tall). A button size in between (32px) would provide a good option that may be more appropriate for a lot of apps.

[basham]

The font size for small buttons (16px) seems too large for the 24px height. Reducing it to 14px makes the text much more comfortable in that space. Plus, it would provide better contrast against other button sizes, if we would introduce a 32px tall button.

[levimcg]

This is a nice improve on the small button variant. We'll plan to move forward with in future beta releases 👍🏻

[basham]

Primary buttons are the default button type (rvt-button), while the secondary type must be opt-in with an extra class (rvt-button rvt-button--secondary). In practice, this results in developers thinking every button should be primary. However, the opposite is true. Ideally, there is only one primary button on a given page or in a given section, and the rest of the buttons would be secondary. If there is a default button type, it should be secondary. And then you opt-in to primary (rvt-button rvt-button--primary).

[levimcg]

@basham This is a really interesting thought. I've kicked around the idea of refining some of the secondary button styles, or what you're proposing as the default button style here. For example using a lighter value for the 2px blue border to create some additional contrast and give the actual button text a bit more visual weight. I always feel like when they're used together, the default button and the secondary button are competing for attention a little too much.

Maybe it would be a good time to explore the idea of changing the default button as you mention. I'm creating some internal task to track some of these other buttons updates, so I'll make a note about exploring this when we get to those updates.

[basham]

There's often times that it is aesthetically better for a button to look like a link. However, rvt-link doesn't work on buttons well. Either rvt-link could be expanded to also be used on buttons, or we could add a new button type (rvt-button rvt-button--link or rvt-link-button or rvt-button-link).

[basham]

There's a number of issues with the use of loading indicators in buttons. Those issues are explore more in depth in #543 (and associated CodePens).

[basham]

The Rivet docs on buttons doesn't mention anything about disabled buttons. It may be good to explain some best practices, tips, or patterns.

For example, a pattern may be to disable submit buttons until the form is valid. This can cause a number of issues. Invalid fields need to clearly outline why they're invalid. And screen reader users navigating in forms mode (tabbing) can't find the submit button, since tabbing skips disabled controls. The user is looking for the submit button, and landing on the submit button informs them when they're at the end of the form. By skipping the disabled submit button, the user has a much more difficult time knowing how to proceed.

This could be solved in a couple ways. First, the submit button should never be disabled. Then when submitting, the form validates, and focus moves to either the first invalid field or an alert summarizing the errors at the top of the form. Second, the submit button could be functionally disabled with aria-disabled and JavaScript, and this retains the ability to put focus on the button (see Making Disabled Buttons More Inclusive). You'd still need to handle showing validation messages.