The Cascade and Inheritance in Depth

Module 01 introduced the cascade at a surface level: later rules override earlier ones when specificity is equal. Lesson 05 added specificity. This lesson completes the picture with the full cascade resolution order and gives you the tools to control inheritance explicitly.

The full cascade resolution order

When multiple rules target the same element and property, the browser resolves the conflict in this order:

Origin and importance — where the rule comes from and whether it uses !important
Specificity — the selector’s score
Source order — which rule appears later in the stylesheet

Each step is only reached if the previous step results in a tie. Two rules with equal origin and equal specificity are resolved by source order.

Step 1: Origin

CSS rules come from three sources:

Origin	Description
Author	Your stylesheet — the one you write
User	Styles set by the user in their browser settings
User agent	The browser’s built-in default stylesheet

Priority (without !important):

Author styles win over user and user-agent styles
User styles win over user-agent styles
User-agent styles are the baseline everything else overrides

!important inverts this order: !important in a user stylesheet beats !important in an author stylesheet — this exists so users with accessibility needs (such as high-contrast requirements) can always override site styles. In practice, you will never encounter this edge case, but it explains why !important is not simply “most powerful.”

Step 2: Specificity

As covered in Lesson 05 — the rule with the higher specificity score wins.

Step 3: Source order

When origin and specificity are equal, the rule that appears later wins — in the same file, or across files if multiple stylesheets are linked.

/* First rule */
.tour-name { color: #2c4a1e; }

/* Second rule — wins because it appears later */
.tour-name { color: #3a5c26; }

Inheritance revisited

Inheritance is the mechanism by which some CSS property values flow from a parent element to its children automatically.

body {
  font-family: Georgia, serif;
  color: #1a1a1a;
  line-height: 1.6;
}

Every element inside <body> inherits these values unless they set their own. This is how setting font-family once on body styles the entire page.

What inherits

Common properties that inherit:

color
font-family, font-size, font-style, font-weight
line-height, letter-spacing
text-align, text-transform
list-style
cursor, visibility

Common properties that do not inherit:

background-color, background-image
border, outline
margin, padding
width, height
display, position, float

The rule of thumb: properties that control visual appearance of text tend to inherit. Properties that control layout and box dimensions do not.

Controlling inheritance explicitly

CSS provides four keyword values for controlling inheritance:

inherit — forces the property to inherit from the parent, even if it would not normally.

a {
  color: inherit;  /* links use their parent's color, not the browser's default blue */
}

button {
  font-family: inherit;  /* buttons use the page font, not the browser default */
}

inherit is especially useful for form elements (<input>, <button>, <select>) — browsers apply their own default fonts to these, and inherit brings them in line with the rest of the page.

initial — resets the property to its CSS specification default, ignoring inheritance and any set values.

.reset-color {
  color: initial;  /* black, per the CSS spec */
}

unset — behaves as inherit if the property naturally inherits, or initial if it does not. A single keyword for “remove whatever was set and go back to natural behavior.”

.unset-all {
  all: unset;  /* resets every property on this element */
}

revert — resets to the browser’s default stylesheet value, not the CSS spec default. More useful than initial for restoring natural browser appearance.

Designing stylesheets to avoid specificity wars

The most common source of specificity problems is selectors that are more specific than they need to be.

Signs you have a specificity problem:

You are adding more and more selectors to override a rule
You are using !important more than once
Changing a style in one place breaks something in another

Practical guidelines:

Use classes, not IDs, in CSS. IDs have triple the specificity of a class and cannot be reused.

Keep selectors as flat as possible. .card h3 is fine; main section .card .card-content h3 is a specificity timebomb.

Do not qualify class selectors with type selectors unless necessary. .nav-link is better than a.nav-link — the type selector only adds specificity without adding clarity.

Structure your stylesheet from low specificity to high specificity — base styles first, component overrides second, state overrides last.

Exercise

In your Summit Trail Outfitters stylesheet, audit for specificity issues:

Look for any rule that uses !important. If you added one during debugging, remove it and fix the selector instead.
Look for selectors longer than two parts. For example, if you have main section .tour-card h3, can it be reduced to .tour-card h3? Reduce it.
Ensure form elements inherit the page font by adding:

input,
textarea,
select,
button {
  font-family: inherit;
  font-size: inherit;
}

Confirm that links inside .site-nav still display correctly after any refactoring — descendant selectors like .site-nav a are fine and intentional.

Module 02 Recap

The full cascade resolution order: origin/importance → specificity → source order.
Author stylesheets override user-agent defaults. !important inverts origin priority.
Specificity scores: ID (A) beats class/pseudo-class (B) beats type (C).
Inheritance passes values from parent to child for text-related properties. Box and layout properties do not inherit.
inherit, initial, unset, and revert give explicit control over inheritance.
Design for low specificity: prefer classes over IDs, keep selectors short, layer from low to high specificity.

Module 03 introduces the box model — how every element occupies space, and how margin, padding, and border control that space.