Overriding Default Button Styles

There are a variety of “buttons” in HTML. You’ve got:
Button

Plus, for better or worse, people like having links that are styled to match the look of other true buttons on the site
Button
One challenge is getting all those elements to look and layout exactly the same. We’ll cover that a few ways.
Another challenge is getting people to use them correctly
This is a bit surprising to me — but I hear it often enough to worry about it — is that more and more developers are using

s for buttons. As in, they just reach for whatever generic, styling-free HTML is handy and build it up as needed. Andy Bell explains why a real button is better:
So, elements are a pain in the butt to style right? That doesn’t mean you should attach your JavaScript events to a

or an though. You see, when you use a

, you get keyboard events for free. You’re also helping screen reader users out because it’ll announce the element correctly.
And here’s Andy again helping you out with a chunk of CSS that’ll get you a cleanly styled button:
See the Pen Button Pal — some basic button styles by Andy Bell (@hankchizljaw) on CodePen.
It’s that styling that just might be the mental roadblock
It’s a bit understandable. Buttons are weird! They have a good amount of default styling (that come from the “User Agent Stylesheet”) that varies from browser to browser and means you have work to do to get them exactly how you want.
See all the weirdness there?
Without any styling, the button is kinda little and has that native border/border-radius/box-shadow thing going on.
Just by setting the font-size, we lose all those defaults, but it’s got a new default look, one with a border and square corners, a gradient background, and no box-shadow. This is essentially -webkit-appearance: button;.
Buttons have their own font-family, so don’t inherit from the cascade unless you tell it to.
Here’s Chrome’s user agent stylesheet for buttons:

Firefox behaves a bit differently. See in the video above how setting border: 0; removed the border in Chrome, but also the background? Not the case in Firefox:

I only point this out to say, I get it, buttons are truly weird things in browsers. Factor in a dozen other browsers, mobile, and the idea that we want to style all those different elements to look exactly the same (see the opening of the article), and I have a modicum of empathy for people wanting to avoid this.
Never hurts to consult Normalize
Normalize does a good amount:
/**
* 1. Change the font styles in all browsers.
* 2. Remove the margin in Firefox and Safari.
*/
button,
input,
optgroup,
select,
textarea {
font-family: inherit; /* 1 */
font-size: 100%; /* 1 */
line-height: 1.15; /* 1 */
margin: 0; /* 2 */
}
/**
* Show the overflow in IE.
* 1. Show the overflow in Edge.
*/
button,
input { /* 1 */
overflow: visible;
}
/**
* Remove the inheritance of text transform in Edge, Firefox, and IE.
* 1. Remove the inheritance of text transform in Firefox.
*/
button,
select { /* 1 */
text-transform: none;
}
/**
* Correct the inability to style clickable types in iOS and Safari.
*/
button,
[type=button],
[type=reset],
[type=submit] {
-webkit-appearance: button;
}
I was a tiny bit surprised to see WTF, Forms? not cover buttons, only because of how much weirdness there is. But the form elements that project whips into shape are even more notoriously difficult!
A Style-Testing Kinda Thingy
I feel like the answer to this is basically a big ol’ block of CSS. That’s what Andy provided, and you could very likely come to one on your own by just being a little heavier handed than the usual of setting style rules with your buttons.
Still, I felt compelled to make a little tester machine thingy so you can toggle styles on and off and see how they all go together in whatever browser you happen to be in:
See the Pen Consistent button styles by Chris Coyier (@chriscoyier) on CodePen.
A11y
The biggest point here is to use the correct native elements, as you get a bunch of functionality and accessibility for free. But you might as well get the styling right, too!
While we’re talking buttons, I’m gonna use the same quote I used in our When To Use The Button Element post from MDN:
Warning: Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered through the Enter key. In other words, when links are used to behave like buttons, adding role=button alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons.
You don’t need role=button on because they are already buttons, but if you’re going to make any other element button-like, you have more work to do to mimic the functionality.
Plus, don’t forget about :hover and :focus styles! Once you’ve wrangled in the styles for the default state, this shouldn’t be so hard, but you definitely need them!
button:hover,
button:focus {
background: #0053ba;
}
button:focus {
outline: 1px solid #fff;
outline-offset: -4px;
}
button:active {
transform: scale(0.99);
}