The cascade and specificity

When rules disagree

In real projects, several rules often target the same element and set the same property to different values. The browser needs a fair way to decide which one wins. That process is the cascade, and it is the "C" in CSS.

<style>
  p { color: grey; }
  .intro { color: teal; }
  p { color: purple; }
</style>
<p class="intro">Which colour am I?</p>
<p>And which colour am I?</p>

The first paragraph is teal, the second purple. Why teal beats a rule written later is what this lesson explains.

The three questions the browser asks

For each property of each element, the browser looks at every matching declaration and asks, in order:

1. Where does it come from, and is it !important? Your styles beat the browser's built-in defaults. !important declarations beat normal ones.
2. How specific is the selector? A more specific selector wins.
3. Which came last? If the first two are tied, the declaration that appears later in the CSS wins.

The browser only moves to the next question when the previous one is a tie. In the example, both color rules for the first paragraph are normal author styles (tie), but .intro is more specific than p, so it wins before order is even considered. For the second paragraph only the two p rules match; they tie on specificity, so the later one, purple, wins.

Calculating specificity

Think of specificity as three numbers, written (IDs, classes, elements):

Compare from the left: the first number that differs decides. That is why one ID, (1,0,0), beats ten classes, (0,10,0). The numbers do not carry over like ordinary arithmetic.

Two special cases: :not(...), :is(...) and :has(...) count as the most specific selector inside their brackets, and :where(...) always counts as zero, which makes it useful for low-priority default styles.

Inline styles and !important

A style="..." attribute on an element beats any selector in a stylesheet. Above that sits !important:

.price { color: crimson !important; }

!important makes a declaration jump ahead of all normal ones. It has a few legitimate uses, such as a utility class that must always work, or overriding a third-party widget you cannot edit. As a habit it is harmful: the next person who needs to change the colour has to use !important too, and soon nothing can be changed without it.

Debugging a style that will not apply

<style>
  #sidebar a { color: navy; }
  .highlight { color: orange; }
</style>
<div id="sidebar">
  <a href="#" class="highlight">Why am I not orange?</a>
</div>

The link stays navy because #sidebar a is (1,0,1) and .highlight is only (0,1,0). Some honest fixes, best first:

1. Lower the winning selector. Style the sidebar with a class (.sidebar a, (0,1,1)) instead of an ID. Many teams avoid IDs in CSS for exactly this reason.
2. Make your selector match the context: .sidebar .highlight (0,2,0) now beats .sidebar a (0,1,1).
3. Move your rule later, if the specificity is already equal.

To see what is going on, right-click the element and choose Inspect. The Styles panel lists every matching rule, most specific first, with losing declarations crossed out. This one habit saves hours.

Common mistakes

• Fighting specificity with more and more selectors (body div.main .content ul li a), making the next override even harder.
• Styling with IDs, which are very hard to override.
• Reaching for !important before inspecting the element.
• Forgetting that order only matters on a tie. Moving a weaker rule to the bottom of the file does not help.

Exercise

Without running it first, predict the colour of each item, then press Try it on the example above or paste this into an editor to check:

<style>
  li { color: black; }
  .list li { color: green; }
  .item { color: blue; }
  ul li.item { color: red; }
</style>
<ul class="list">
  <li>One</li>
  <li class="item">Two</li>
</ul>