What CSS Is and What the Browser Does With It

HTML says what things are. CSS says how they look and where they sit. JavaScript changes things after the page has loaded. That split is the reason CSS exists, and most CSS pain comes from forgetting it.

Take a heading. In HTML it is an h1, which tells the browser, a screen reader and a search engine that this is the top-level title. Whether it is blue, 48px or centered has nothing to do with its meaning. That part belongs to CSS.

<h1>Pricing</h1>

h1 {
  color: #0b5fff;
  font-size: 3rem;
  text-align: center;
}

Delete the CSS and the page still works. Delete the HTML and the CSS has nothing to attach to. The dependency runs one way: CSS decorates a structure that already stands on its own.

Why it is called "cascading"#

Håkon Wium Lie proposed CSS in 1994 while working at CERN, and CSS1 became a W3C Recommendation in 1996. The "cascading" part was there from day one. A page can receive styles from several places at once: the browser's own defaults, the user's settings, and the author's stylesheets. A defined order decides who wins when they disagree.

You will spend all of Module 2 on that order, because it is the source of nearly every "why is my style not applying" question you will ever ask.

CSS also has no version 4. After CSS2.1 the specification was split into independent modules (Selectors, Flexbox, Grid, Color and so on) that evolve at their own speed. "CSS3" is just a label for everything that came after the split. In practice, this means you check browser support per feature, not per version.

What happens between your file and the screen#

The browser does not read CSS top to bottom and "run" it. It builds data structures, then calculates. The sequence looks like this:

HTML bytes ──► DOM ──────────┐
                             ├─► Render tree ─► Layout ─► Paint ─► Composite
CSS bytes  ──► CSSOM ────────┘   (computed       (size &    (draw    (stack layers,
                                  styles)         position)  pixels)  send to screen)

Each stage has a job:

1. DOM. The HTML parser turns tags into a tree of objects.
2. CSSOM. The CSS parser does the same for your stylesheets: a tree of rules the browser can query.
3. Render tree. For every visible element, the browser works out which rules match it and resolves the cascade. The result is a computed value for every single property on that element.
4. Layout. Using those computed values, the browser calculates the width, height and position of every box. This is the expensive stage, because one box moving can push dozens of others.
5. Paint. Boxes are turned into drawing instructions: backgrounds, borders, text, shadows.
6. Composite. Painted layers are stacked in the right order, often on the GPU, and shown on screen.

CSS blocks rendering, on purpose#

A browser will not paint a page until it has built the CSSOM for stylesheets in the head. If it painted early, users would see raw unstyled HTML for a moment and then watch everything jump. That flash has a name: FOUC, a flash of unstyled content.

The side effect is that a slow stylesheet makes the whole page look blank. This is why you link CSS in the head, keep the file lean, and avoid chains where one stylesheet has to load before the browser even discovers the next one (the next lesson covers that).

Every property always has a value#

You never wrote display: block for a div, yet it behaves like a block. Browsers ship a built-in stylesheet, called the user-agent stylesheet, that gives div its display: block, gives h1 a large bold font, and gives a its blue underline.

Beyond that, every CSS property has an initial value defined by the spec. If nothing sets margin on a span, the computed value is still 0. There is no such thing as an element with an "unset" property at the end of the pipeline.

Open DevTools on any element and look at the Computed tab. You will see around 300 properties, all with values, most of which you never touched. That is the output of the cascade.

CSS is declarative#

In JavaScript you write steps. In CSS you describe a target state: "paragraphs inside .card are gray, 1.1rem". The browser decides when and how to apply it, and it re-applies it automatically whenever the DOM changes, the window resizes, or the user hovers something.

Two consequences follow:

• Order of rules matters only when rules conflict. There is no "execution" order for unrelated rules.
• You cannot write "if this, then that" in the traditional sense. Conditions are expressed through selectors, media queries and feature queries.

What your change costs#

Not every change costs the same, because it restarts the pipeline at a different stage:

This table is the reason animation advice always says "animate transform and opacity". Module 7 comes back to it with real examples.

Common mistakes#

• Using HTML for looks. <center>, <font> and <b> for emphasis come from before CSS existed. Pick tags for meaning, then style them.
• Expecting an error message. CSS never throws. A typo in a property name is silently skipped, and the page just looks wrong. DevTools shows invalid declarations with a strikethrough and a warning icon.
• Treating div as magic. div and span have no meaning and almost no default styling. If a button or nav fits, use it. You inherit behavior and accessibility for free.
• Testing in one browser. The spec is shared, but support for newer features is not. Check support before depending on a feature.

Practice#

1. Create an index.html with one h1, two paragraphs and a link. Open it with no CSS at all.
2. Open DevTools, select the h1, and find the rule from the "user agent stylesheet" in the Styles pane. Write down its font-size and margin.
3. In the Computed tab, find the computed value of display for the h1, the link and a paragraph. Explain why they differ.
4. Add a style block that makes the h1 blue. Watch the Styles pane and note which rule has the strikethrough now.