Session 3: CSS Box Model & Typography

A CSS rule has two parts: a selector saying what to style, and declarations saying how. `h2 { color: navy; }` selects every `<h2>` and sets its colour. The element selector is the bluntest tool available — it styles every instance — which is why classes exist: `<p class="intro">` and `.intro { … }` style only the paragraphs you marked.

The rule for choosing is straightforward. Use a class for anything you style more than once or might want to style differently later, which is most things. Use an ID for something genuinely unique — and be aware that an ID carries more weight than a class, so it is harder to override later, which is why IDs are better used for JavaScript hooks and page anchors than for styling. Use an element selector for defaults that should apply everywhere, like body font or heading colour.

Then specificity, which decides what wins when two rules conflict. Roughly, an ID beats a class, a class beats an element, and among equals the later rule wins. Most 'why is my CSS not working' problems are specificity problems, and the wrong fix is adding `!important` — which wins today and creates a rule you cannot override tomorrow. The right fix is a simpler, more specific selector.

Every element on a page is a rectangular box, and the box has four layers: the content, then padding (space inside the box, between the content and its edge), then the border, then margin (space outside the box, between it and its neighbours). Understanding those four is most of CSS layout, because everything else is arranging boxes.

The part that confuses everyone is what `width` means. By default, `width: 200px` sets the width of the content only — add padding and a border and the element becomes visibly wider than 200px. So a 200px box with 20px of padding and a 1px border is 242px across, which breaks layouts in ways that seem arbitrary until you know this.

The fix is one line, and it should be at the top of every stylesheet: `*, *::before, *::after { box-sizing: border-box; }`. This makes `width` mean the whole box, padding and border included, which is what everyone expects and what makes layouts predictable. Setting it once removes an entire category of confusion, and virtually every modern project does it.

Elements are either block — they take a full line and stack vertically, like `<p>` and `<div>` — or inline — they sit within a line and only take the width of their content, like `<a>` and `<strong>`. This is why margin-top does nothing useful on an inline element, and why setting a width on one appears to be ignored. Knowing which is which explains a great deal of otherwise mysterious behaviour.

Then margin collapsing, the behaviour that surprises everyone first. When two vertical margins meet — the bottom of one block and the top of the next — they do not add up; the larger one wins. So a paragraph with 20px below followed by one with 30px above has 30px between them, not 50px. It is not a bug, and knowing it prevents a great deal of confused spacing adjustment.

Spacing itself is a design decision more than a technical one. Consistency reads as deliberate: pick a small scale — 4, 8, 16, 24, 32, 48 pixels — and use only those values. Random spacing looks untidy even when nobody can say why. And space things by relationship: elements that belong together sit closer than elements that do not, which is how a reader understands grouping without being told.

Typography is most of what makes a page feel professional, and it comes down to four decisions. Size: body text at 16px or larger — anything smaller is hard to read on a phone, which is where most people will read it. Line height: about 1.5 times the font size for body text, because cramped lines are tiring and loose lines lose the thread. Line length: roughly 45 to 75 characters, which is why a full-width paragraph on a wide screen is unpleasant to read.

Then font choice. Use a system font stack or one well-made web font, and load no more than two families, because each one is a file someone has to download on a slow connection — a real cost here. A stack like `-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif` renders instantly with no download and looks good everywhere, which is usually the right answer for a small project.

And hierarchy through contrast, not variety. A page needs a clear order of importance — heading sizes, weights and spacing doing the work — rather than five different fonts at similar sizes. Set headings in relative units (`em` or `rem`) so they scale with the base size, and never set text below about 14px for anything anyone needs to read.

Colour needs three things: a limited palette, sufficient contrast, and a job. A palette of two or three colours plus neutrals looks deliberate; a page with eight accent colours looks accidental. Define them once as CSS custom properties — `--brand: #0b6b3a;` — so changing the palette later is one edit rather than a search through the whole stylesheet.

Contrast is a requirement, not a preference. Body text needs at least 4.5:1 against its background. Light grey on white fails badly and is the single most common reason a site that looks elegant is genuinely hard to read — for people with low vision, and for anyone on a phone in daylight, which describes most of Nigeria.

Then never rely on colour alone to carry meaning, and use colour consistently: one colour for primary actions, one for errors, one for success, applied the same way everywhere. A user learns your colour language in a few seconds, and inconsistent use breaks it. Also remember that roughly one in twelve men has some colour vision deficiency, so red-versus-green distinctions — the classic error-and-success pairing — need a text or icon indicator alongside them.