I used to think CSS was polite. Declarative. Predictable. I would write a rule, refresh the browser, and expect the page to bow respectfully. Instead, it would shrug and do something else. A margin would vanish. A color would refuse to change. A layout would collapse like a tavern table after one too many tankards.
What I eventually learned is that CSS is not polite. It is lawful.
The cascade is not chaos. It is a rule system. A hierarchy. A quiet tribunal that decides which declaration lives and which one fades into obscurity. Once I stopped fighting it and started studying it like a wizard studies a spellbook, everything changed.
In this first entry of The CSS Codex, I will walk through the laws that govern the cascade and show how they operate in real code. Think of this as your field guide before entering the dungeon.
The Three Pillars of the Cascade
The cascade rests on three core principles: origin, specificity, and source order. If two declarations target the same element and property, the cascade uses these principles to determine the winner.
Imagine two rival mages attempting to enchant the same sword. The cascade decides whose magic holds.
Let us begin with a simple example.
<!DOCTYPE html>
<html>
<head>
<style>
p {
color: blue;
}
.highlight {
color: red;
}
</style>
</head>
<body>
<p class="highlight">The arcane laws are watching.</p>
</body>
</html>The paragraph selector sets the text color to blue. The class selector sets it to red. Both target the same element. Which wins?
The answer is red.
The class selector has higher specificity than the type selector. Specificity is a scoring system. It assigns weight to selectors based on their components.
Type selectors such as p or div are light infantry.
Class selectors such as .highlight are seasoned fighters.
ID selectors such as #hero are legendary champions.
The cascade compares their scores before it even looks at order.
Specificity: The Arcane Math
Specificity can be understood as a four part value written conceptually as:
inline styles, IDs, classes or attributes, type selectors
Consider the following:
p {
color: green;
}
.container p {
color: orange;
}
#main .container p {
color: purple;
}And the HTML:
<div id="main">
<div class="container">
<p>The spell deepens.</p>
</div>
</div>The final color is purple.
Why?
Because the selector #main .container p includes an ID, a class, and a type selector. It carries far more weight than a simple p selector.
If we break it down:
p has a specificity of 0,0,0,1
.container p has 0,0,1,1
#main .container p has 0,1,1,1
The highest value in the leftmost column that differs wins. The ID gives the third selector decisive power.
When debugging CSS, I often imagine the browser performing this comparison like a council of judges reading scrolls and tallying marks.
Source Order: The Last Word
If specificity ties, source order decides the winner. The later declaration overrides the earlier one.
Observe this:
.button {
background-color: gray;
}
.button {
background-color: black;
}Both selectors have identical specificity. The second rule appears later in the stylesheet. Therefore, the button becomes black.
This seems simple, but in large codebases it becomes dangerous. If two modules define the same class, the one loaded last wins. If you do not understand the order of your stylesheets, you are adventuring without a map.
Origin: The Hidden Hierarchy
The cascade also considers origin. Styles can come from:
User agent styles, which are the browser defaults
Author styles, which are your stylesheets
User styles, which are custom styles set by the user
Author styles typically override user agent styles. However, the presence of important changes the equation.
Let us examine important.
p {
color: blue !important;
}
.highlight {
color: red;
}Even though .highlight is more specific, the p selector with important wins. The paragraph will be blue.
Important elevates a declaration above normal cascade rules. It is the nuclear option. It overrides specificity within the same origin.
I treat important as a cursed artifact. It solves problems quickly but often creates greater ones later. If you find yourself stacking important repeatedly, you have likely angered the cascade instead of working with it.
Inheritance: The Bloodline of Styles
Some properties inherit automatically from parent elements. Color is one of them. Margin is not.
Consider this:
body {
color: darkslategray;
font-family: Georgia, serif;
}All text inside the body inherits these values unless explicitly overridden.
Inheritance is a quiet ally. It allows you to define foundational styles high in the document tree and let them flow downward.
Imagine a royal decree issued at the castle. Every village under its banner follows the same law unless a local magistrate overrides it.
Understanding which properties inherit and which do not saves countless lines of CSS.
The Modern Twist: Cascade Layers
Modern CSS introduces cascade layers using the at layer rule. Layers allow you to control precedence more explicitly.
Example:
@layer base {
p {
color: green;
}
}
@layer components {
p {
color: red;
}
}If the layers are defined in this order:
@layer base, components;Then the components layer overrides base, regardless of source order inside the file.
This is powerful. It allows you to define architectural intent. Base styles, layout styles, component styles, utility styles. Each can occupy its own tier in the cascade.
In larger systems, I structure styles like a campaign manual:
base for resets and typography
layout for grid and structure
components for reusable elements
utilities for single purpose overrides
By declaring layer order intentionally, I remove ambiguity from the cascade.
A Real World Example: Taming a Card Component
Let me demonstrate how these laws interact in practice.
HTML:
<div class="card featured">
<h2 class="card-title">Codex Entry</h2>
<p>The laws are written in glowing ink.</p>
</div>
