CSS Selectors, the Cascade and Specificity Explained

A plant nursery prints a price tag for each plant. The designer wants every price in green. She writes color: green, reloads, and the price is purple. She did not write purple anywhere near that rule. Welcome to the most common CSS confusion: several rules match one element and the browser has to choose. The mechanism is called the cascade, and once you can compute it by hand you will stop guessing and start fixing.

Selectors choose the elements

A CSS rule is a selector plus a block of declarations. The selector decides which elements are affected. Start with the building blocks, then combine them.

Whitespace is meaningful. .tag.sale (no space) matches one element that has both classes. .tag .sale (with a space) matches a .sale element somewhere inside a .tag. That single space is behind a large share of "my selector does nothing" questions. Recent browsers also support :is(), :where() and :has() for grouping and for selecting a parent based on its children; check compatibility tables before using :has() in production.

A page that fights back

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Price tag</title>
  <style>
    #fern .price   { color: purple; }
    p              { color: grey; }
    .tag .price    { color: green; }
    article p.price{ color: red; }

    .tag           { font-family: Georgia, serif; border: 1px solid #2d4a2d; padding: 12px; width: 220px; }
  </style>
</head>
<body>
  <article class="tag sale" id="fern">
    <h2 class="name">Boston Fern</h2>
    <p class="price">12.50</p>
    <p class="note">Water twice a week</p>
  </article>
</body>
</html>

The page shows a 220-pixel-wide card with a thin dark-green border and 12 pixels of padding. Inside: "Boston Fern" as a bold heading, the price in purple, and the note in grey. All four colour rules match the price paragraph, and purple is declared first, so how did it win? Count the parts of each selector.

Compare the columns from left to right, never adding them together. One id outranks any number of classes, and one class outranks any number of element names. #fern .price has (1, 1, 0), which beats (0, 2, 0) at the first column, so purple wins even though it is the first of the four rules in the file and three later rules also match. Source order only breaks ties between equal specificity.

The order the cascade uses

1. Importance and origin. A declaration with !important beats a normal one, and your styles generally beat the browser's default styles.
2. Cascade layers. If you use @layer (supported in current browsers), a later layer beats an earlier one for normal declarations, regardless of specificity.
3. Specificity. Inline style="" beats any selector; then ids, then classes, attributes and pseudo-classes, then types and pseudo-elements.
4. Source order. If everything above is a tie, the declaration that appears last wins.

Inheritance is a separate mechanism. Some properties, such as color, font-family and line-height, pass from parent to child when the child has no rule of its own. The nursery card sets font-family: Georgia on .tag, and the heading and both paragraphs pick it up without being targeted. But inheritance is the weakest influence there is: any rule that directly matches an element, even p { color: grey } with specificity (0, 0, 1), beats an inherited value. Properties like border, margin and padding do not inherit.

Fixing it without a fight

The wrong fix is !important: it raises the stakes, and the next person must also use it. The right fix is to remove the accidental high-specificity rule. Here the id selector is the problem, so style by class and let source order decide.

/* Base: low specificity, easy to override */
p { color: grey; margin: 0 0 8px; }

/* Components: one class each */
.tag   { font-family: Georgia, serif; }
.price { color: green; font-weight: 700; }
.note  { font-size: 0.875rem; }

/* State: slightly higher specificity on purpose */
.tag.sale .price { color: #b3261e; }   /* (0, 3, 0) */

.price::before { content: "\0024 "; }  /* adds a dollar sign visually */

Now the sale tag shows the price in red, bold, with a generated dollar sign before the number, while a non-sale tag would show it green. The card's colours are decided by one class each, plus one deliberate extra-specific rule, so it is obvious which rule is supposed to win. This is the same idea behind naming systems such as BEM: keep selectors flat so specificity stays predictable.

Common mistakes

• Forgetting the dot or hash. price { color: green } targets a <price> element that does not exist, so nothing happens and nothing errors.
• A typo in a property or value. colour: green or color: gren is dropped silently; DevTools shows the declaration with a warning icon and strikethrough.
• Missing semicolon. color: green followed by font-weight: 700 on the next line merges into one invalid declaration, so both are lost.
• Reaching for `#id` selectors in a stylesheet. One id rule can only be beaten by another id or !important, and your later class rules mysteriously fail.
• `!important` everywhere. Overrides now need !important too, and the stylesheet turns into an arms race.
• A stale stylesheet. You edit the file and see no change because the browser cached it; hard-reload or tick "Disable cache" in DevTools.

How this shows up in real projects and interviews

Specificity wars are a staple of legacy code, and "how does CSS decide which rule applies?" is a classic front-end interview question. The answer to give is the ordered list above, followed by a worked specificity comparison like the table. In a component framework, scoped styles or utility classes reduce conflicts, but they still sit on top of the same cascade. If you work in React, see React Components and Props for how class names flow into the markup that your CSS targets.