I’ve never specifically covered this subject before. (rimshot!)

The best way to explain it is to start with an example of where specificity gets confusing and perhaps doesn’t behave like you would expect. Then we’ll take a closer look at how to calculate the actual specificity value to determine which selector takes precedence.

Here is a simple unordered list:

<ul id="summer-drinks">     <li>Whiskey and Ginger Ale</li>     <li>Wheat Beer</li>     <li>Mint Julip</li>  </ul>

Now you want to designate one of these your favorite drink and change its styling a bit. You need a hook for this so you apply it via a class name on the list element.

<ul id="summer-drinks">     <li class="favorite">Whiskey and Ginger Ale</li>     <li>Wheat Beer</li>     <li>Mint Julip</li>  </ul>

Now you pop open your CSS and do your styling for your new class:

.favorite {    color: red;    font-weight: bold;  }

Then you take a look at your work, but alas, it didn’t work! The text of your favorite drink didn’t turn red or go bold! Something fishy is at work here.

Poking around more in the CSS, you find this:

ul#summer-drinks li {     font-weight: normal;     font-size: 12px;     color: black;  }

There is your trouble right there. Two different CSS selectors are telling that text what color and font-weight to be. There is only one statement for font-size, so clearly that one will take effect. These aren’t “conflicts” per-say, but the browser does need to decide which one of these statements to honor. It does so by following a standard set of specificity rules.

I think this confuses some beginners because they haven’t quite gotten this sorted out yet. They might think because the .favorite statement is “further down in the CSS” or because the is “closer to the actual text” in the HTML that will be the one that “wins”.

In fact, the order of selectors in your CSS does play a role and the “further down” one does in fact win when the specificity values are exactly the same. For example:

.favorite {     color: red;  }  .favorite {     color: black;  }

The color will be black… but I digress.

The point here is you want to be as specific as it makes sense to be every chance you get. Even with the simple example presented above, it will become obvious to you eventually that simply using a class name to target that “favorite drink” isn’t going to cut it, or won’t be very safe even if it did work. It would have been smart to use this:

ul#summer-drinks li.favorite {    color: red;    font-weight: bold;  }

That is what I’m calling “being as specific as it makes sense to be”. You could actually be way more specific and use something like this:

html body div#pagewrap ul#summer-drinks li.favorite {    color: red;    font-weight: bold;  }

But that is over the top. It makes your CSS harder to read and yields no real benefits. Another way to juice up the specificity value for your “.favorite” class is to use the !important declaration.

.favorite {    color: red !important;    font-weight: bold !important;  }

I once heard it said that !important is like the Jedi mind trick for CSS. Indeed it is, and you can force your will over the styling of elements by using it. But !important imposes that will through drastically increasing the specificity of that particular selectors property.

The !important declaration can be easily misused if misunderstood. It is best used to keep your CSS cleaner, in examples where you know elements with a particular class selector should use a certain set of styling no matter what. Conversely, not used just as a quick crutch to override the styling of something instead of figuring out how the CSS was structured and working by the original author.

One of my classic examples is:

.last {     margin-right: 0 !important;  }

I often use that in situations where there are multiple floated blocks, for the last block on the right in a row. That ensures the last block doesn’t have any right margin which would prevent it from butting snugly against the right edge of its parent. Each of those blocks probably has more specific CSS selectors that apply the right margin to begin with, but !important will break through that and take care of it with one simple/clean class.

Calculating CSS Specificity Value

Why is that our first attempt at changing the color and font-weight failed? As we learned, it was because simply using the class name by itself had a lower specificity value and was trumped by the other selector which targeted the unordered list with the ID value. The important words in that sentence were class and ID. CSS applies vastly different specificity weights to classes and IDs. In fact, an ID has infinitely more specificity value! That is, no amount of classes alone can outweigh an ID.

Let’s take a look at how the numbers are actually calculated:

In otherwords:

• If the element has inline styling, that automatically¹ wins (1,0,0,0 points)
• For each ID value, apply 0,1,0,0 points
• For each class value (or pseudo-class or attribute selector), apply 0,0,1,0 points
• For each element reference, apply 0,0,0,1 point

You can generally read the values as if they were just a number, like 1,0,0,0 is “1000″, and so clearly wins over a specificity of 0,1,0,0 or “100″. The commas are there to remind us that this isn’t really a “base 10″ system, in that you could technically have a specificity value of like 0,1,13,4 – and that “13″ doesn’t spill over like a base 10 system would.

Sample calculations

Important Notes

• The universal selector (*) has no specificity value (0,0,0,0)
• Pseudo-elements (e.g. :first-line) get 0,0,0,1 unlike their psuedo-class brethren which get 0,0,1,0
• The !important value appended a CSS property value is an automatic win. It overrides even inline styles from the markup. The only way an !important value can be overridden is with another !important rule declared later in the CSS and with equal or great specificity value otherwise. You could think of it as adding 1,0,0,0,0 to the specificity value.

Resources

• Smashing Magazine has a pretty comprehensive article on CSS Specificity
• W3 spec on specificity in CSS3
• IE Quirks (try viewing this page in Fx and then IE)
• Fuzzy Specificity Hack: IE (even beta 8!) and older Opera browsers have a bug honoring the correct selector under specific circumstances.