Understanding the CSS Cascade

The "C" in CSS stands for Cascading, and it describes the algorithm the browser uses to decide which declaration wins when multiple rules target the same element and the same property. Without the cascade, a stylesheet with conflicting rules would be ambiguous — the cascade makes the outcome predictable.

The cascade resolves conflicts through a strict, ordered sequence: first by origin and importance, then by specificity (covered in the next topic), and finally by source order. Learning this order removes the guesswork from debugging "why isn't my style applying?" — usually the answer lives somewhere in this sequence.

Why it matters

Several rules often set the same property on the same element, and the cascade is the set of rules that decides which one wins. Until you understand it, CSS feels random: a change has no effect, and nobody knows why. Once you do, you can predict the result and stop reaching for !important.

Origin and Importance

CSS declarations come from different origins, and the cascade ranks them before it even looks at specificity.

• User-agent styles — the browser's built-in default stylesheet (e.g. default margins on <body>, default list bullets).
• Author styles — the CSS you write for your site; this is what developers work with day to day.
• User styles — custom styles a site visitor applies (e.g. via browser extensions or accessibility settings).
• !important declarations — override normal cascade ordering for that specific origin, and author !important rules beat normal author rules regardless of specificity elsewhere.

Source Order as a Tie-Breaker

When two rules have identical origin, importance, and specificity, the cascade falls back to source order: whichever rule appears later in the stylesheet (or later in the document, for multiple linked stylesheets) wins. This is why the order you write or link your CSS files matters — a later rule with equal specificity silently overrides an earlier one.

Inheritance vs. the Cascade

Inheritance is a separate but related mechanism: some properties (like color, font-family, and line-height) automatically pass from a parent element to its children if nothing else sets them. Properties like margin, padding, and border do not inherit by default. An inherited value has the lowest priority in the cascade, so any explicit rule — no matter how simple — will override an inherited one.

Examples

<!-- <p class="note">Read this carefully.</p> -->

.note {
  color: blue;
}

.note {
  color: green; /* same specificity, appears later -> wins */
}

The paragraph text renders green, because the second .note rule has identical specificity to the first but appears later in the stylesheet.

#sidebar .widget p {
  color: black;
}

p {
  color: red !important; /* wins despite lower specificity, due to !important */
}

All paragraph text renders red, including text inside #sidebar .widget, because !important outranks normal specificity comparisons within the author origin.

Exercise

Set the text colour once on main so that the heading and the paragraph both inherit navy. Then override the paragraph alone to grey with a later rule. Finally, make the button use the inherited colour too; form controls do not inherit text colour by default.

Expected result: a navy heading, a grey paragraph and navy button text.

/* The page contains: <main> with an <h1>, a <p> and a <button> */

/* TODO: navy text for everything inside main */

/* TODO: the paragraph is grey instead */

/* TODO: the button takes the colour of its parent */

/* The page contains: <main> with an <h1>, a <p> and a <button> */

main {
  color: navy;
}

p {
  color: gray;
}

button {
  color: inherit;
}

Quick quiz

Interview questions