buttons

We dug into overriding default buttons styles not long ago here on CSS-Tricks. With garden-variety fully cross-browser-supported styles, you're looking at 6-10 CSS rules to tear down anything you need to off a button and then put in place your own styles. Hardly a big deal if you ask me, especially since it's extremely likely you'll be styling buttons anyway.

Scott O'Hara has taken a look as well including a couple of interesting other CSS explorations, neither of which stacked up for different reasons:

• display: contents; - some semantics-based accessibility problems.
• all: unset; - doesn't reset display value, not good enough browser support.

It took me a little bit to wrap my head around this, including having a little chat with Scott over DMs. I was so confused that the correct way to do what he was laying out was <span role="button" tabindex="0" onClick="...">. What?! I thought. It's almost never the correct thing to do to force a non-button element to behave like a button and have to replicate all the button functionality in other ways. And indeed, if you just have like a word-or-two kinda button, you probably don't need to, and can just un-do button styles. The trouble comes in here: you cannot un-do inline-block on a <button>. Apparently, it's just impossible. You can set it to display: inline; and it will take it, but it won't behave like it.

Tyler Sticka on the complexity of designing buttons and making sure that we’ve taken into consideration focus, hover and active states during the design process:

In truth, mouse effects are probably the least important state to design for. By accounting for more functional states early, you can lower the need for costly redesigns as your pattern library matures. Here are the fundamental states you should address early on, in approximate order of importance.

I’ve been spending a lot more time lately thinking about focus styles as being a crucial challenge when building for the web and so I particularly take Tyler’s advice to heart. He argues that we should repeat this maxim throughout the button design process:

"I do solemnly swear never to disable browser focus styles without including a thoughtfully designed replacement."

The first step: focusing on focus styles.

On a related note, we recently did a series on CSS Basics that included a post dedicated to link styling for various link states. Also, there’s a pretty good post that’s related to this topic called Buttons in Design Systems that tackles a bunch of UX considerations for buttons, like how to write a good label.

I really like this post by Nathan Curtis where he discusses how buttons can be applied to a design system:

I love buttons. I can do things with buttons. Take a next step. Make a commitment. Get things done. With buttons, interaction springs to life.

That’s why Buttons are arguably a design system’s most important component. Devilishly simple, they offer a simple label in a defined region I can press. As such, buttons are where you apply a design language’s base attributes in ways that’ll ripple throughout more complex component later.

Borders, colors, text styles, icons; there’s so much to consider! But what I really wanted to make a quick note of here is the idea of resilience in a design, particularly where Nathan talks about adding components inside a button, like an icon:

When you add an element, even a simple icon, a button layout shouldn’t break down. Coping with less predictable elements reveals pesky issues of spacing and alignment inside.

So whenever you remove a component from inside a button then the button itself should still work. But this isn’t just important for buttons really, it’s important for any component that we’re building. In short: asking questions about how a certain element might break visually, or in terms of interaction, is vital to the process of building an effective design system.