Lesson

The id selector wins. Browsers rank competing rules by specificity, not by which one appears last in the file: id selectors outrank class selectors, which outrank plain tag selectors. Source order only acts as a tiebreaker when two rules have exactly equal specificity. An inline style attribute beats all three, and !important beats almost everything else. Underneath that ranking, the browser is literally counting selectors in three columns — IDs, then classes/attributes/pseudo-classes, then tag names — and comparing the counts left to right like a tiebreaker. A single ID scores (1, 0, 0) and beats any number of classes, say (0, 7, 0), because the comparison stops at the first column where the two differ.

Every CSS rule has the same shape: a selector, followed by a declaration block in curly braces, where each declaration pairs a property with a value and ends in a semicolon. A single rule can hold several declarations at once — h1 { color: red; font-size: 40px; } sets both the color and the size of every <h1> in one block. That semicolon is not optional punctuation: drop it between two declarations and the browser folds the next property name into the previous value, silently breaking only that one declaration while the rest of the rule keeps working.

CSS can be added to a page three ways. Inline CSS lives directly on an element's style attribute and only affects that one element. Internal CSS lives inside a <style> block in the document <head> and affects that one page. External CSS lives in its own .css file, linked with <link rel="stylesheet">. One gotcha worth knowing early: if a page links an external stylesheet and then also has an internal <style> block further down the same <head>, an internal rule will beat an external rule of otherwise equal specificity purely because it appears later on the page — the cascade cares about position in the document, not which of the three methods was used.

One declaration is common enough to belong in nearly every stylesheet before anything else is written: * { box-sizing: border-box; }. By default, the browser adds padding and border on top of an element's declared width, so a box declared at exactly 300px does not actually measure 300px once padding is added. border-box has never become the actual browser default, even though most developers want it everywhere — changing the default now would silently resize every box on every site built under the old assumption, so it stays opt-in instead. The "Why this matters" section below shows exactly how many pixels skipping it can cost a layout.

:root and custom properties — Variables defined with two leading dashes, like --color-primary, are declared once on :root (effectively the <html> element) and reused anywhere with var(--color-primary). They are not the same as Sass or Less variables — custom properties live in the browser itself, can be read or changed with JavaScript at runtime, and can be overridden inside a single component without touching the global value.

The reset block — The * universal selector matches literally everything. Without a block like this, default spacing is not even consistent between browsers — a bare <body> ships with built-in margin in most of them, which is exactly why a page sometimes shows an unexplained gap on every edge until someone adds a reset. Pairing box-sizing: border-box with the margin and padding reset in the same rule is the conventional pattern, since both problems are normally solved together at the very top of a stylesheet.

.card and .btn — These are class selectors, written with a leading dot. Unlike a tag selector, a class can be applied to any element and reused as many times as a page needs, which is why almost every reusable UI piece — cards, buttons, badges, alerts — is styled with a class rather than a tag or an ID. Naming a class after what it is (.btn) rather than how it currently looks (.blue-rounded-button) means the name still makes sense after the next redesign changes the color.

.btn:focus-visible — This is a pseudo-class, written with a colon, that matches an element only in a specific state rather than all the time. Plain :focus would show the outline on every click, including mouse clicks where it is rarely wanted; :focus-visible is smarter and shows the outline mainly when the browser detects keyboard navigation, like pressing Tab. One rule here replaces what would otherwise be a separate, hand-applied style on every interactive element on the page.

.grid and the media query — Setting display: grid turns this element into a grid container, and grid-template-columns: repeat(3, 1fr) splits it into three equal-width columns, with gap adding space between cells directly. Everything inside @media (max-width: 700px) { ... } only applies once the viewport is 700px wide or narrower, and here it overrides just the column count back down to one. Because the original .grid rule still applies underneath it, the gap value carries over untouched — only the property actually redeclared inside the media query changes.

Suppose a rebrand changes the primary brand color. With the color stored once as --color-primary, that is a one-line edit. With the same hex code typed directly into forty separate button rules across a dozen files, it becomes a forty-edit hunt — and missing even one means the site quietly ships two slightly different "primary" colors live at the same time.

Three cards in a 1fr 1fr 1fr grid, each with 20px of padding and a 1px border, look identical to three cards with no padding at all — until box-sizing reverts to the browser default. Then each card's rendered width grows by 42px beyond its grid track, the row no longer fits, and the third card silently drops onto its own line with no error message anywhere to explain why.

The first time a rule will not apply, reaching for !important feels like a fast fix. The second time it happens — often on the very same element, fighting the rule that already has !important on it — the only way to win is a second !important with a more specific selector. Each shortcut makes the next legitimate style change harder to land without yet another override.

A class like .btn can be applied to ten buttons or a thousand and updated everywhere from one rule. Style each button by hand instead, and a single visual change — a new corner radius, a new hover state — has to be found and repeated everywhere it was used, with no guarantee every instance gets caught.

Paste your stylesheet into ChatGPT and ask: "Are there repeated color or spacing values here that should be CSS variables, and are there any specificity conflicts between these rules?" It is good at spotting duplicated values and obvious selector clashes. Be cautious if it suggests adding !important to fix a conflict — that usually patches the symptom while leaving the underlying specificity problem in place. It is also worth asking specifically: "Does this stylesheet remove any default focus outlines without replacing them, and are there color combinations here that might fail a contrast check?" Those are exactly the kinds of accessibility regressions that are easy to introduce by accident and easy for a quick review to catch before they ship.

Create profile_card.html and profile_card.css. Link the CSS file with <link rel="stylesheet"> in the <head>. If a change to the CSS file doesn't show up on reload, open the Network tab in DevTools and check whether profile_card.css actually returned a 200 — a wrong relative path in the href is one of the most common reasons CSS changes seem to do nothing.

In the CSS file, declare three custom properties on :root for a primary color, a text color, and a spacing value. Add a universal reset rule that sets box-sizing: border-box on every element, in the same rule as a margin and padding reset.

Build a .card class with background, padding, and a rounded corner, all using your custom properties instead of hardcoded values. Apply it to a <div> containing a name and a short bio.

Add a .btn class with a hover effect that changes transform or box-shadow, plus a separate :focus-visible rule with a visible outline. Use the class on two different buttons, then navigate to them with the Tab key only — no mouse — and confirm the outline actually appears.

Styling individual elements with inline style attributes instead of a class. It works for that one element, but every repeated visual change then has to be copy-pasted by hand across the page — and because inline styles sit at the very top of the specificity order, they are also the hardest layer to override later from an external stylesheet.

Reaching for an ID selector to style something that might be reused, or might need overriding later. IDs rank just below inline styles in specificity, so a rule written as #header { color: blue; } cannot be beaten by any class-based rule afterward — the only way around it is another ID, an inline style, or !important, none of which make the next change easier.

Reaching for !important to win a specificity fight instead of fixing the selector that is too weak — or too strong — underneath it. It does win, but it also disables the normal specificity order for that property going forward, so the next person debugging the page in DevTools cannot tell which rule "should" apply just by reading selectors; they have to go hunting for the !important first.

Writing a selector that depends on exact HTML structure, like div.sidebar > div > ul > li > a, instead of giving the link its own class. The styling works today, but the moment a designer wraps that link in one more <span> or a developer reorders the markup, the selector silently stops matching and the link loses its styling with no warning anywhere.

Skipping the box-sizing: border-box reset, then debugging why a row of flex items overflows its container by a few pixels. Padding and border are added on top of the declared width under the browser default, so four boxes that should fit exactly across a 100%-wide row end up a little too wide combined, and the last one wraps onto its own line for no visible reason.

Lesson

Unlocking…

lesson

Back to Logout

First question

Main example

Code walkthrough

Why this matters

Bad vs better

Avoid this

Better

AI can help, but you still check

Try it yourself

Need more help?

① Open ChatGPT in a new tab.
② Come back here and copy this lesson prompt.
③ Paste it into ChatGPT.
④ Press Enter and learn one question at a time.

Open ChatGPT

Common mistakes

moc.rt-tij [ta] troppus

(customization available)

moc.rt-tij [ta] troppus

(customization available)