Session 3: CSS Fundamentals

CSS reaches HTML three ways. Inline, in a `style` attribute on an element — useful for nothing except a quick experiment, because it cannot be reused and it is nearly impossible to override later. Internal, in a `<style>` block in the head — fine for a single-page experiment. External, in a separate `.css` file linked with `<link rel="stylesheet" href="styles.css">` — which is what you will use for everything real.

The external file is not a preference, it is the architecture. One stylesheet can restyle an entire site, so changing the brand colour becomes a one-line edit instead of a hundred; the browser caches it, so every page after the first loads faster; and the separation keeps HTML readable, which matters when you return to a client's site eight months later to change one thing. The convention is one folder with `index.html`, `styles.css` and an `images` folder — simple, obvious, and what every other developer expects.

A selector picks which elements a rule applies to. The ones you need constantly: an element selector (`p`, `h2`) targets all of that type; a class selector (`.card`) targets anything carrying `class="card"` and is reusable, which makes it the workhorse; an id selector (`#hero`) targets one unique element and should be rare, because it cannot be reused and it is difficult to override; a descendant selector (`.card p`) targets paragraphs inside cards; and a pseudo-class like `a:hover` targets a state.

When two rules conflict, the cascade decides, in this order. Specificity first: an id beats a class, a class beats an element, so `#hero { color: red }` defeats `.title { color: blue }` even if the class rule comes later. Where specificity ties, source order wins — the later rule beats the earlier one, which is why the order of your stylesheet matters and why a reset or base stylesheet always goes first. Inline styles beat all of those, and `!important` beats everything, which is exactly why you should almost never use it: it does not solve a specificity problem, it buries it, and the next person to edit the file inherits a puzzle.

The practical discipline is to write most rules against classes and keep specificity flat. When you find yourself chaining selectors to win a fight — `.page .section .card p` — that is a signal the stylesheet is disorganised, not that you need a longer selector.

Every element on a page is a rectangle, and that rectangle has four layers working outward: the content, then padding (space inside the element, between content and its edge), then the border, then the margin (space outside, pushing other elements away). Every layout problem you will ever meet is one of these four being a value you did not expect, which is why the box diagram in dev tools is the first place to look when something is misplaced.

The trap is how width is calculated. By default, `width: 300px` means the content is 300 pixels and padding and border are added on top, so the element actually occupies more than 300 — which is why a 300px box with 20px padding and a 1px border is 342 pixels wide and does not fit where you expected. The fix is one line at the top of every stylesheet: `*, *::before, *::after { box-sizing: border-box; }`. With border-box, the width you declare is the width the element occupies, padding and border included, which makes layout arithmetic behave the way your head expects it to. Write it once and forget it; omit it and lose hours.

Then learn the difference between block and inline elements, because it governs what you can do to them. A block element — `div`, `p`, `h1` — takes the full available width and starts on a new line, and accepts width, height, margin and padding fully. An inline element — `span`, `a`, `strong` — sits within a line, and width and height are ignored on it. When a width or a margin mysteriously does nothing, the usual reason is that the element is inline.

Declare colour as custom properties at the top of your stylesheet — `:root { --brand: #C2410C; --ink: #1A1A1A; --surface: #FAF7F2; }` — and then use `var(--brand)` everywhere. This is not ceremony. It means the entire site's palette lives in one place, so a rebrand is four lines rather than a search-and-replace across a file, and it makes the palette visible to anyone reading the code. It is also the mechanism behind dark mode and theme switching, should a client ever ask.

Use the palette discipline from Graphic Design: a dominant, a secondary neutral, a text colour and one accent, in roughly 60-30-10 proportions. And check contrast, because it is a requirement rather than a preference: body text needs at least 4.5:1 against its background. Low-contrast grey text on white is the most common accessibility failure on Nigerian business sites, and it is invisible to the person who designed it on a calibrated screen in a dim room — which is why you measure it rather than judge it.

Prefer a near-black like `#1A1A1A` over pure `#000000` for text, and an off-white over pure white for large backgrounds. Pure black on pure white creates harsh edges and reads as unrefined; the softened pair looks more considered for exactly the same effort.

Type carries more of a page's quality than anything else. Declare a font stack rather than a single family — `font-family: 'Inter', system-ui, sans-serif` — so that if the web font fails to load, the system font takes over rather than the browser's default serif. Load web fonts from Google Fonts with a `<link>`, but load only the weights you use, because each weight is another file to download and font loading is one of the most common causes of a slow page.

Set a base size on `body` — 16px to 18px is right for reading — then size headings from a scale using `rem` units, which are relative to that base. A 1.25 ratio from an 18px base gives roughly 22.5, 28 and 35px. Using `rem` rather than `px` means the whole page respects a user who has increased their browser's default text size, which is a real accessibility behaviour and one that `px` silently defeats. Set line height around 1.5 for body text and 1.15 for headings, and constrain body copy to roughly 60–75 characters per line with `max-width`, because a line running the full width of a desktop is genuinely hard to read.

Finally, spacing. Do not invent margins element by element — define a scale as custom properties (`--space-1: 0.5rem; --space-2: 1rem; --space-3: 2rem; --space-4: 4rem`) and use only those values. A page whose spacing comes from a scale looks ordered even when nobody can say why; a page whose margins were chosen individually looks arbitrary even when every individual choice was reasonable. This one habit is the largest single visual improvement available to a beginner's work, and it costs nothing.