# The good kind of specificity in CSS

Here I’m trying to figure out what forms the specificity in CSS? What is the
good kind of specificity, what bad specificity is, and how to use only the good
kind of specificity.

## What is specificity in CSS?

Specificity is the "weight" of the selector, upon the browser decides which
style rule is the most relevant for the given element. In other words: which
style rule has the most power.

## What makes the specificity in CSS?

It’s these 5 things:

1. Inline styles have higher specificity than styles in the style sheet.
2. Selector order, later one wins.
3. IDs have higher specificity than classes.
4. Cascading increases specificity.
5. `!important` rule increases specificity.

Let’s look at them one by one.

### 1 Inline styles have higher specificity

```html
<style>
  #my-button {
    background-color: blue;
  }
</style>

<button id="my-button" style="color: red;">Hello</button>
```

That button will be red.

### 2 Selector order

Later on in the file defined rules have higher specificity:

```css
.button {
  background-color: blue;
}

.button {
  background-color: red;
}
```

That button will be red.

### 3 IDs have higher specificity than classes

The below button should be blue:

```css
#button {
  background-color: blue;
}

.button {
  background-color: red;
}
```

### 4 Cascading increases specificity

That button will be blue:

```css
body .button {
  background-color: blue;
}

.button {
  background-color: red;
}
```

The following button will also be blue:

```css
button.button {
  background-color: blue;
}

.button {
  background-color: red;
}
```

### 5 The !important rule increases specificity

```css
.button {
  background-color: blue !important;
}

.button {
  background-color: red;
}
```

Results in blue button.

## Demo

See this [simple JSBin Demo](https://jsbin.com/qugefoqofe?source=css).

## The good kind of specificity

> 1 Inline styles have higher specificity

This good, when adding a class to an element with JavaScript, it needs to
override existing styles.

> 2 Selector order

We want the later rules in the file to have the power to override earlier rules.

## The bad kind of specificity

I think **there are too many ways an element’s specificity can change**. If we
want to make our programming life simple, the **selector order** and
**inlining** should be only two ways to affect selectors specificity.

Say you have a big website with +20 000 lines of CSS, and on a specific page you
want to make element green on hover, rather than red, but you can’t, **because
somewhere in those +20 000 lines there is a rule with a higher specificity than
your new rule**, even if it comes last in the CSS. So now you have to use
`!important` to override the specificity and the vicious circle of specificity
hell is set.

## The simple solution to the specificity madness

Here’s some quotes to set the mood of this section:

> Only a madman would use the whole of C++

And one from the JavaScript Cthulhu, aka Crockford:

> Most programming languages contain good parts and bad parts. I discovered that
> I could be better programmer by using only the good parts and avoiding the bad
> parts.

A pivotal moment in my working life was deciding to restrict my CSS to exclude
the things that caused me pain:

1. Stop the use of IDs to style elements.
2. Stop the cascade, give the element a class and go straight in.
3. If you stop those two things, then you also don’t need `!important`.

## Conclusions

Nothing is set in stone, there might be some cases where cascading is a great
option. Not using IDs and discarding cascading doesn’t make you a good
programmer, and using them will not make you a bad programmer.