How CSS Works

Your Styles Don't Apply the Way You Think

You write color: red and the text turns red. Feels like magic, right? But between your declaration and the final pixel color, the browser runs a multi-stage pipeline: parsing, tokenizing, building a tree, resolving conflicts across multiple origins, calculating specificity, handling inheritance, converting relative values to absolute ones, and finally resolving layout-dependent values during rendering.

Here's the thing -- understanding this pipeline is the difference between debugging CSS by trial and error and debugging it by knowing which stage went wrong.

Stage 1: Parsing CSS Into the CSSOM

So what actually happens when the browser encounters a <link> tag or <style> block? It hands the raw bytes to the CSS parser. The parser:

1. Decodes bytes into characters using the specified encoding (UTF-8 by default)
2. Tokenizes characters into CSS tokens — identifiers, strings, numbers, delimiters
3. Parses tokens into a tree of rules, selectors, and declarations
4. Builds the CSSOM (CSS Object Model) — a tree structure mirroring the DOM

/* This CSS text... */
body {
  font-size: 16px;
  color: #333;
}

.header {
  font-size: 2rem;
}

/* ...becomes a CSSOM tree:
   StyleSheet
   ├── CSSStyleRule (selector: "body")
   │   ├── font-size: 16px
   │   └── color: #333
   └── CSSStyleRule (selector: ".header")
       └── font-size: 2rem
*/

CSS parsing is forgiving. Unlike JavaScript, an invalid CSS declaration doesn't crash the parser. The browser silently discards what it can't understand and keeps going:

.box {
  color: red;
  font-size: ????; /* Invalid — browser ignores this line */
  background: blue; /* This still applies */
}

This error recovery behavior is why CSS feature detection works — old browsers ignore display: grid because they can't parse it, and the fallback display: block still applies.

Stage 2: The Cascade Algorithm

This is where it gets interesting. When multiple declarations target the same property on the same element, the cascade resolves the conflict. The algorithm checks — in order:

1. Origin and Importance

CSS has three origins, checked in this priority order (highest to lowest for normal declarations):

Now here's the part that surprises everyone: for !important declarations, the priority order reverses. User agent !important beats author !important. This protects accessibility — a user's high-contrast stylesheet can override your design.

2. Specificity

If two declarations have the same origin and importance, specificity breaks the tie. Specificity is calculated as a three-component tuple (ID, CLASS, ELEMENT):

/* (0, 0, 1) — one element selector */
p { color: blue; }

/* (0, 1, 0) — one class selector */
.text { color: green; }

/* (1, 0, 0) — one ID selector */
#intro { color: red; }

/* (0, 1, 1) — one class + one element */
p.text { color: purple; }

/* (1, 1, 1) — one ID + one class + one element */
p#intro.text { color: orange; }

3. Source Order

If origin and specificity are equal, the declaration that appears last in source order wins.

.box { color: red; }
.box { color: blue; } /* Wins — same specificity, later source order */

Stage 3: Computed, Used, and Resolved Values

You'd think we're done after the cascade picks a winner. Not quite. The value goes through several more transformations:

Specified Value

The value declared in CSS after cascade resolution, or the inherited/initial value if no declaration exists.

Computed Value

Relative values resolved as far as possible without layout:

• em converted relative to parent font-size
• rem converted relative to root font-size
• inherit resolved to parent's computed value
• Relative URLs made absolute

/* If root font-size is 16px and parent font-size is 20px */
.child {
  font-size: 1.5em;    /* Computed: 30px (1.5 × 20px parent) */
  width: 50%;          /* Computed: 50% (can't resolve without layout) */
  margin: 2rem;        /* Computed: 32px (2 × 16px root) */
}

Used Value

The value after layout. Percentages that depend on containing block dimensions are resolved here:

.child {
  width: 50%; /* Used: 400px (if containing block is 800px wide) */
}

Actual Value

The final value after rounding and device constraints. If the device can't render 14.7px borders, the actual value might be 15px.

Production Scenario: "Why Doesn't My Override Work?"

/* library.css (loaded first) */
.btn.btn-primary { /* Specificity: (0, 2, 0) */
  background: #007bff;
}

/* app.css (loaded second) */
.custom-btn { /* Specificity: (0, 1, 0) */
  background: #ff6600; /* Doesn't win — lower specificity */
}

The fix is not !important. Resist that urge. The real fix is understanding the cascade:

/* Option 1: Match or exceed specificity */
.btn.custom-btn {
  background: #ff6600; /* (0, 2, 0) — ties, but later source order wins */
}

/* Option 2: Use a cascade layer (modern approach) */
@layer library, app;

@layer library {
  .btn.btn-primary { background: #007bff; }
}

@layer app {
  .custom-btn { background: #ff6600; } /* Layer order wins over specificity */
}