Webpage: Anyone Can Build It

Plate 0.1 · Phase 0 — Ground Floor · 20 minutes

What actually happens when you visit a website

Before you write a single line of anything, you need one picture in your head. Everything else in this manual hangs off it — and most beginners never get given it.

Why this is the very first thing

People who struggle with web development are almost never struggling with typing. They are struggling because they don't know where their code goes, who runs it, or when. They write something, it doesn't work, and they can't even tell which of the four possible places the problem is in. Twenty minutes now saves you months of that.

So: you open your phone, tap the address bar, type rei.com, and press go. A page appears in about a second. What just happened?

The restaurant

You walk into a restaurant and sit down. You can see the dining room. You cannot see the kitchen, and you will never be allowed in it.

Hold on to that last row of the table, because it is the single most important line in this module.

The round trip, six steps

Press the button and walk through it. This exact sequence happens every time you open any page, on any device, anywhere.

Reading a web address like a professional

A URL isn't a magic string. Every piece of it does a specific job, and once you can read one you can guess how almost any site is organized. Click each part.

https://www.rei.com/products/running-shoes?color=black#reviews

Proof: a web page is just text you can read

This is the moment most people stop being intimidated. Below on the left is text — the same kind of text a server sends you. On the right is what a browser makes of it. Change a word on the left and watch the right update as you type. Nothing can break; it's your copy.

<h1>Hello, I am a web page</h1>

<p>A server sent this as plain text.
Your browser did the rest.</p>

<p style="color: teal">
  Try changing teal to crimson.
</p>

<button>I am a real button</button>

That's it. That's the entire secret of the front end: you write instructions in text, the browser turns them into something people can see and touch. Phase 1 is nothing but learning which instructions exist.

Do this now — 5 minutes, on a real website

Reading about it does nothing. Open a laptop or desktop browser (this exercise needs a real keyboard) and follow along on any site you like.

1. Open any website — a news site is ideal because they're heavy.
2. Right-click anywhere on the page and choose Inspect. Or press F12, or Ctrl+Shift+I on Windows, Cmd+Option+I on Mac. A panel opens. This is DevTools, and it ships free inside every browser. It is the single most useful thing on your machine.
3. Click the Network tab, then reload the page. Watch the rows pour in. Every row is one round trip — one of those six-step journeys. Look at the count at the bottom. Fifty? Two hundred? Now you know what "a page" actually costs.
4. Click the Elements tab. Move your mouse down the lines of code and watch parts of the page highlight. That is the HTML the server sent — the instruction sheet from the flat-pack box.
5. Find the main headline in that code, double-click its text, type your own name, press Enter. The headline on the page changes. Screenshot it if you like.
6. Now press reload. Your name is gone. Sit with that for ten seconds — it's the whole point of the exercise.

Three things beginners get wrong

1. "The website lives in my browser." It doesn't. It lives on a server; you keep receiving temporary copies. When a site updates and you still see the old version, you're looking at a copy your browser kept to save time — a cache. A hard refresh fetches a fresh copy: Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac.

2. "The internet and the web are the same thing." The internet is the road network. The web is one kind of traffic on it. Your email app, a video call and an online game all drive the same roads without ever being web pages.

3. "Real developers work on the live site." Almost never. You build a copy on your own machine, where mistakes cost nothing, and only then push it out. Phase 5 is entirely about doing that safely.

Words you now own

client

Whatever asks for the page. Nearly always your browser.

server

The always-on computer that holds the site and answers requests.

request

The message asking for something specific.

response

What comes back: a file, plus a status number like 200 or 404.

HTTP / HTTPS

The agreed format of those messages. The S means encrypted.

DNS

The internet's phone book: turns a name into a number.

IP address

That number — a computer's location on the network.

URL

A full web address, made of the parts you dissected above.

render

The browser's act of turning text instructions into pixels.

DevTools

The free inspection panel built into your browser.

Plate 0.2 · Phase 0 — Ground Floor · 15 minutes

The three languages of every web page

Every website you have ever used is made of exactly three things. Being able to say instantly which of the three is misbehaving is the fastest debugging skill in the trade — and you can have it in fifteen minutes.

Why classifying beats fixing

When a professional sees something wrong on a page, their first move is not to fix it. It is to put it in a bucket. There are only three buckets, and whichever one the problem lands in tells them which file to open and which half of their knowledge to use.

Beginners skip this step. They see a broken page, feel a wave of panic, and start changing things in whichever file happens to be open. An hour later they've edited the wrong file in four places. This module is the antidote, and it's the shortest one in the manual.

One body, three systems

Picture a person standing in front of you.

Watch the layers come off

Below is a real product card — the same kind of component you'll build yourself in Phase 2 and bring to life in Phase 4. Flip the switches and watch what survives. Nothing here is a picture; it's a live thing being stripped.

Three things are worth noticing while you play with that.

With CSS off, nothing is lost. Every word, every price, every link is still there — just plain, stacked, with the browser's own default look from 1995. This is roughly what a screen reader hears and what a search engine reads. If your page makes no sense in this state, it makes no sense to a blind user or to Google either.

With JavaScript off, everything looks perfect and nothing works. That gap — beautiful and dead — is one of the most common bug reports you will ever receive, and it always points at the same bucket.

With both off, you're looking at the raw delivery. That's the flat-pack box from Module 0.1, before assembly.

The three, side by side

That third row matters more than it looks. HTML and CSS are not general-purpose programming languages, and saying so is not an insult — it's a description. You can't use either one to store a customer's order, add up a basket, or decide what to do next. HTML labels things; CSS states rules about things (and CSS can do some clever calculations for layout). JavaScript is the only one of the three that can remember, decide and repeat.

How the three find each other

The HTML file is the boss. It's the one the browser asks for in step 3 of the round trip, and it invites the other two in by name:

<link rel="stylesheet" href="styles.css">
<script src="app.js" defer></script>

Think of the HTML file as the house's address. Those two lines are the notes it leaves out front: decorator, let yourself in, and electrician, come after the decorator. You'll write both lines by hand in Module 1.1 and they will then be muscle memory forever.

Order is real, and it's the source of an entire genre of beginner bug. The browser reads the HTML from top to bottom, applies the CSS as it goes, and runs the JavaScript when it reaches it. If your script runs before the button it's looking for has been created, the script finds nothing and stops — the page shows no sign of it, and the only clue is a red error in the Console. That word defer above means "wait until the HTML is finished." Remember that it exists; Module 4.1 explains why.

Whose fault is it? — the triage drill

This is the module's whole point, so do it properly. Read each symptom, decide the bucket, then commit to an answer before reading the reasoning.

Do this now — 4 minutes on a real website

You did the DevTools warm-up in 0.1. This time you're going to take a real, professionally built site apart in front of your own eyes. Use a laptop or desktop.

1. Open a site you use often. Open DevTools (F12, or Cmd+Option+I on Mac) and go to the Elements tab.
2. Go to wikipedia.org and open any article. Near the top of the Elements tab, inside <head>, find a line starting with <link rel="stylesheet". Click it once to select it, then press Delete. The clothes come off. Sit with how much of the site still works. (Many big sites hide their styles inside the page instead, so deleting one line changes nothing there — that's why we use Wikipedia.)
3. Reload to put them back on.
4. Now, with DevTools still open, press F1 to open DevTools settings (or click the gear icon), tick Disable JavaScript, and reload the page. Go back to a site you use often for this step — one with menus, search and carousels.
5. Try the things a page does rather than shows: the search box, the hamburger menu, an image carousel, an "add to cart" button, an infinite-scroll feed. Note which ones died.
6. Untick it. Then write one sentence: on this site, CSS was responsible for ___ and JavaScript was responsible for ___. If you can fill that in, you have this module.

Three things beginners get wrong

1. "JavaScript is a version of Java." It is not, and they are unrelated. The name was a marketing decision in 1995 when Java was fashionable. The classic line: Java and JavaScript are related the way a car and a carpet are. Don't buy a Java book by mistake — people do, every year.

2. "I should learn all three at once so I can build something real." A page with only HTML is something real — it loads in every browser on earth, works offline, and is fully readable. Build three plain ones before you touch CSS. It will feel too simple. That feeling is the whole point: you'll be adding one layer to something that already works instead of debugging three unknowns at once.

3. "CSS is the easy one." HTML is genuinely learnable in a couple of weeks. CSS is where working professionals lose the most hours — layout, responsiveness, and one style rule quietly overriding another. Phase 2 gets ten modules for a reason.

Words you now own

markup

Text with labels wrapped around it to say what each part is. HTML is markup.

element

One labeled thing on the page — a heading, an image, a button.

tag

The label itself, in angle brackets: <p> opens, </p> closes.

attribute

Extra information on a tag, like href on a link or src on an image.

stylesheet

A file of CSS rules, usually shared by every page on a site.

selector

The part of a CSS rule that says which elements it applies to.

script

A file of JavaScript, and the tag that loads it.

defer

An instruction telling a script to wait until the HTML has finished loading.

Plate 0.3 · Phase 0 — Ground Floor · 20 minutes

Files, folders and the developer's filing cabinet

This is the least glamorous module in the manual and one of the two or three most useful. Almost every "my image won't show up" and "my styles aren't loading" in your first six months will be a problem from this page.

Why a whole module on filenames

In Module 0.2 you saw an HTML file invite in a stylesheet and a script by name. That name is an address. If the address is wrong by one character — a capital letter, a space, a missing folder — the browser goes looking, finds nothing, and says nothing about it. Your page just quietly appears broken.

Two skills fix that permanently: knowing how to write an address from where you're standing, and naming things so the address is never ambiguous in the first place. Twenty minutes, and you will never lose an afternoon to it.

Giving directions to a file

Suppose a friend asks where the pharmacy is. You have two honest ways to answer.

Work it out yourself

Here is an ordinary small project. Pick the file you're writing in, pick the file you want to reach, and the correct path appears — with the reasoning, so you can do it in your head next time.

portfolio/
├─ index.html          the home page
├─ about.html
├─ css/
│  └─ styles.css
├─ js/
│  └─ app.js
└─ images/
   ├─ logo.svg
   └─ photos/
      └─ hero.jpg

<link rel="stylesheet" href="css/styles.css">
<a href="../index.html">Read more</a>
background-image: url(../images/logo.svg);

Notice what happens when you write from css/styles.css to images/logo.svg: you have to step up and out of css first. That leading ../ is not decoration — remove it and the browser hunts for portfolio/css/images/logo.svg, a folder that has never existed.

Naming things so they never bite you

Six rules. They look fussy. Every one of them exists because of a bug that cost somebody a working day.

Type any filename below — one of your own from your Downloads folder is a good test — and see what a professional would flag.

The shape of a project

Every small site you build in Phases 1 and 2 will look like the tree above, and there is nothing arbitrary about it: one folder per kind of thing, and one HTML file per page, all sitting at the top where they're easy to find.

Two conventions inside that shape are worth memorizing now.

index.html is a magic name. When a visitor asks for a folder rather than a file — yoursite.com/ or yoursite.com/blog/ — the server looks inside and serves index.html without being told. That's why home pages are called index. Name it home.html and your site's front door stops working.

One project, one folder. Everything a site needs lives inside a single top folder, and nothing outside it is ever referenced. That's what makes a project something you can zip up, hand over, put in version control (Module 5.2) or upload to a host (Module 5.6) and have it just work.

Three things beginners get wrong

1. Hidden file extensions. Windows hides known extensions by default, so you save "index.html" in Notepad and actually get index.html.txt — which the browser shows as text instead of a page. Turn extensions on today. Windows 11: File Explorer → View → Show → File name extensions. Windows 10: File Explorer → View → tick File name extensions. Mac: Finder → Settings → Advanced → Show all filename extensions. Do it before Module 1.1.

2. Absolute paths from your own computer. Something like C:\Users\Jaybee\Desktop\site\logo.png will display perfectly on your screen and on nobody else's. If a path contains your name or a drive letter, it is wrong.

3. Renaming files after linking them. Nothing updates automatically. Rename hero.jpg to hero-2.jpg and every reference to it goes stale in silence. Rename deliberately, then search your project for the old name — a habit your editor makes easy in Module 0.4.

Words you now own

directory

The formal word for a folder. Same thing.

path

The written address of a file: folders separated by /.

relative path

Counted from the file you're writing in.

absolute URL

A complete address starting with https:// — works from anywhere.

root-relative path

Starts with /, counted from the top of the website. Needs a web server; breaks on a double-clicked file.

parent — ..

One folder up. ../ at the start of a path means "step out first".

extension

The bit after the last dot. It tells software what kind of file this is.

index.html

The file a server serves when someone asks for a folder.

Documents/
└─ projects/
   └─ portfolio/
      ├─ css/
      ├─ images/
      │  └─ harbor-sunset.jpg      ← your photo, renamed
      └─ js/

Plate 0.4 · Phase 0 — Ground Floor · 25 minutes

Your workshop: VS Code and DevTools

Two free tools, set up once, that you will spend the next several years inside. Twenty-five minutes now, and then — this is the point — you stop thinking about your tools and start thinking about your work.

Set the bench up once

A carpenter doesn't rearrange the workshop every morning. The bench is at the right height, the tools most often reached for are within arm's length, and the light is good. That setup was decided years ago and is now invisible; all the attention goes to the wood.

Beginners in this trade do the opposite. They spend week three watching videos comparing editors, week five switching color themes, week seven installing forty extensions. It feels productive and it is not building anything. So: install these two things, learn seven shortcuts, and get on with it.

The editor

You will write code in a text editor built for code. It colors your code so mistakes stand out, completes what you're typing, tells you about errors as you make them, and lets you search an entire project in a second.

Use Visual Studio Code. It is free, made by Microsoft, runs on Windows, Mac and Linux, and roughly three of every four developers use it. That last part matters more than any feature: every tutorial, every answer on Stack Overflow, and every colleague who looks over your shoulder assumes VS Code.

Install it

1. Go to code.visualstudio.com and download the version for your system. The big blue button is the right one.
2. Windows: run the installer, and tick "Add to PATH" and "Open with Code" when offered. Mac: drag the app into your Applications folder.
3. Open it. Skip the theme picker for now — you can decorate later.

Four extensions. Not forty.

Extensions live behind the square blocks icon in the left bar (or Ctrl/Cmd + Shift + X). Search each by name, click Install, and then close the panel and leave it closed for a month.

Three settings worth changing while you're here. Open the Command Palette (see below), type "settings", choose Preferences: Open Settings (UI), then search for and set:

• Auto Save → onFocusChange. Your work saves itself whenever you click away from the editor — to the preview, the browser, anywhere.
• Default Formatter → Prettier - Code formatter. Without this, VS Code keeps using its own formatter and Prettier sits idle.
• Format On Save → ticked. Now Prettier tidies every file each time it's saved.

Why not the tempting afterDelay option for Auto Save? Because VS Code deliberately skips formatting on those timed saves — with it, Prettier would never run. onFocusChange gives you both.

Seven shortcuts that pay for themselves in a week

Not fifty. Seven. Use each one three times today and they're yours.

If you only keep one, keep the first. The Command Palette is a search box for everything the editor can do — you don't need to know which menu a feature is hiding in, only roughly what it's called.

The other half of the workshop: DevTools

You've already opened DevTools twice, in 0.1 and 0.2. It's time to learn what the tabs actually are, because between them they answer nearly every question you'll have about a page. Click through them here first; they'll be familiar when you open the real thing.

Your first two lines of JavaScript, right now

The Console isn't only for reading messages — it's a place where you can type JavaScript and have it run immediately, against whatever page you're on. You don't know JavaScript yet. Do this anyway; it takes forty seconds and it makes the language concrete a long time before Phase 3.

1. Open any website, press F12, click the Console tab, and click in the empty space next to the >.
2. Type 2 + 2 and press Enter. It answers. It's a calculator.
3. Type document.title and press Enter. It tells you the page's title — document is JavaScript's name for the page you're on.
4. Type document.body.style.background = "hotpink" and press Enter. Look at what happened. (If nothing seems to change, the site has covered its body with other boxes — try it on wikipedia.org or example.com.)
5. Reload. It's gone, for exactly the reason you learned in Module 0.1.

That last line is the whole of the front end in miniature: you reached into the structure (document.body), changed an appearance property (style.background), and the browser repainted instantly. Three languages, one line, and you just wrote it.

Three things beginners get wrong

1. Shopping instead of building. There is no editor, theme or extension that will make the next module easier. Set it up, then don't touch it until something specific annoys you.

2. Installing everything. Extensions overlap, argue with each other, and slow the editor down. Four is right for now. Add one only when you can name the problem it solves.

3. Ignoring the red squiggles. Your editor is trying to tell you something before you've even run the file — that is the cheapest bug report you will ever get. Error Lens exists to make it impossible to walk past.

Words you now own

editor / IDE

The program you write code in. VS Code sits between a plain editor and a full IDE.

extension

An add-on that teaches your editor a new trick.

syntax highlighting

Coloring code by meaning so mistakes stand out visually.

IntelliSense

VS Code's autocomplete — suggestions as you type.

formatter

A tool that rewrites your code's spacing to a consistent shape. Prettier is one.

live reload

The page refreshing by itself when you save a file.

localhost

Your own computer acting as a web server. Live Preview gives you an http://localhost:3000 address instead of a file:/// one — closer to how the real thing behaves.

Command Palette

The search box for every command the editor has.

PORTFOLIO
 ├ css
 │  └ styles.css
 ├ images
 │  └ harbor-sunset.jpg
 ├ js
 │  └ app.js
 └ index.html

Plate 0.5 · Phase 0 — Ground Floor · 15 minutes

Website, web app, or native app?

The first four modules were knowledge. This one is judgment — the first time you're asked to decide something rather than learn something. It is also the question you will be asked more than any other, usually in these words: "Can you build me an app?"

Why the professional answers with a question

When someone says "app", they almost never mean a specific technology. They mean the thing on my phone that solves my problem. Four quite different things fit that description, they cost wildly different amounts, and choosing wrong is expensive in a way that isn't obvious for about six months.

So the professional response isn't "sure, $40,000". It's "tell me what people will actually do with it" — and then a recommendation with reasons attached. By the end of this module you can give that recommendation.

Four kinds of premises

Think about a business choosing where to trade.

Decide it yourself

Tick everything the thing genuinely has to do — not what would be nice, what it has to do. The recommendation updates as you go, and tells you which requirement pushed it up a level.

Notice how few things force you all the way to native — and notice that all of them are about hardware and the operating system, never about how serious or ambitious the idea is. Figma, Google Docs, Google Sheets and Gmail are all web apps.

What each choice actually costs you

That fourth row is the one people underestimate. Every step between "saw the link" and "using the thing" loses a large share of people. A link goes straight there. An install asks for a store visit, a download, a password and a permission dialog — before anyone has seen a single benefit.

Three real briefs

Read each one, decide out loud before you reveal the answer, and say two reasons. This is the assessment for this module, so don't skim it.

What this means for your path

Everything in this manual builds static sites and web apps, and the PWA layer sits on top of what you'll already know. That covers the honest answer to the great majority of "can you build me an app?" conversations you will ever have.

And if a project genuinely needs native one day, you won't be starting over. React (Phase 6) is the same mental model as React Native; JavaScript and TypeScript come with you; the backend in Phase 7 is identical whether a browser or a phone app is talking to it. Nothing here is wasted.

Three things beginners get wrong

1. Assuming native means serious. It means a store listing, a review queue, a percentage of your revenue, and an install screen between you and every user. Those are costs, not credentials.

2. Assuming "web app" means small. Figma runs a full design tool in a tab. Google Sheets recalculates a hundred thousand cells in one. The browser stopped being the limitation a long time ago.

3. Calling a responsive website an app. A site that looks good on a phone is still a site. The line isn't the screen size — it's whether people do things that are remembered afterwards.

Words you now own

static site

Pages that are the same for everyone, served as files.

dynamic site

Pages built per request, so different people see different things.

web app

Software you use in a browser rather than content you read.

SPA

Single-page app: one page that rewrites itself instead of loading new pages. Module 6.8.

PWA

A web app that can be installed, works offline, and can notify.

native app

Built for one operating system and installed from its store.

cross-platform

One codebase producing both iOS and Android apps — React Native, Flutter.

install friction

Everyone lost at each step between hearing about it and using it.

Plate 0.6 · Phase 0 — Ground Floor · 20 minutes · Final module of Phase 0

Domains, hosting and DNS in plain language

This is the module that stops you being overcharged. The three things below get sold as one bundle by companies that would rather you didn't know they're separate — and two of the three are usually free.

Three purchases people think are one

A small business in Austin decides to go online. They call a web company and are quoted $1,800 up front plus $45 a month "for the website". Nobody explains what the $45 buys. Here is what is actually being sold.

Three separate things, from three companies if you like. Bundle them at one provider for convenience if you want — but know you are choosing to, not obliged to.

The domain: you are renting a name

You buy a domain from a registrar — Cloudflare, Porkbun, Namecheap and GoDaddy are the common ones — and you pay every year, forever. Miss the renewal and it goes back on the market, where someone else may take it. That is the single most expensive mistake in this module, and it is entirely preventable: turn on auto-renew the day you buy.

The hosting: where your files actually sit

Hosting is renting space on a computer that never sleeps. There are four kinds, and knowing which is which is how you avoid paying for a tractor to carry a lunchbox.

Read the first row again. Every static site in this manual — your portfolio, a client's restaurant site, a landing page — can be hosted free on today's plans, on infrastructure faster than what that $45 a month was buying. You'll do it yourself in Module 5.6, and it takes under ten minutes.

DNS: the directory in the middle

You own a name. You have a building. DNS is the paperwork that connects them, and it's a short list of records. Click each one.

Idea to live website: the actual sequence

1. Build the site. Phases 1 and 2. This is the part that takes real time — and you don't need a domain to do it.
2. Deploy it to a static host. It gives you a working address immediately, something like your-site.netlify.app. Your site is now live on the internet, for free, without a domain at all.
3. Register the domain once you have something worth pointing it at — at a registrar, in your own name, with auto-renew on. Two minutes.
4. Point the domain at it. In your registrar's DNS panel, add the record the host tells you to add — usually a CNAME for www and an A record for the bare name.
5. Wait. Minutes, usually. Meanwhile the host requests a free HTTPS certificate for your domain and installs it. You do nothing.
6. Done. Every future change: save the file, push it, and the live site updates itself in about a minute. That's Module 5.6.

Two things a domain does not include

Email. Owning yourbusiness.com does not give you jagon@yourbusiness.com. Mail is a separate service, connected by MX records. Google Workspace Business Starter is $7 per user per month on annual billing ($8.40 month-to-month); Fastmail, Zoho and Proton are cheaper. A free middle path many people miss: most registrars will forward jagon@yourbusiness.com to an existing Gmail address at no cost, which is often all a small business needs.

Anyone visiting. A domain is an address, not an audience. Getting found is Module 1.5 (structure search engines can read), Module 8.2 (speed, which affects ranking), and a great deal of work that isn't code.

What it honestly costs

Pick what you're building. These are real 2026 numbers, not a sales page's numbers.

Three things beginners get wrong

1. Buying hosting before there's anything to host. You do not need hosting to learn. Everything in Phases 1 through 4 runs from a folder on your own machine. Buy a domain when you have something to put on it.

2. Assuming the bundle is the deal. Registrar, host and DNS at one company is convenient, not cheaper. Free static hosting plus a $12 domain beats almost every "all-in-one" package on both price and speed.

3. Letting someone else hold the keys. The domain, the host account and the DNS should all be in accounts you can log into. If you can't log in, you don't control your website — no matter what the invoice says.

Words you now own

domain

The rented name people type. Yours while you keep paying.

registrar

The company you rent the domain through.

TLD

The ending: .com, .org, .io, .us.

hosting

Rented space on an always-on computer that serves your files.

static hosting

Hosting for files that don't change per visitor. Free at your scale.

A record

Points a name straight at a numeric IP address.

CNAME

Points a name at another name, and follows wherever that one goes.

MX record

Says which mail servers handle email for the domain.

nameservers

Which company's DNS records are the authoritative ones for your domain.

TTL / propagation

How long others may cache a record — why changes take a while to be seen everywhere.

Plate 1.1 · Phase 1 — Framing · 20 minutes · First module of Phase 1

Your first web page, from a blank file

Everything up to now was preparation. In this module you create a file that did not exist, type about twelve lines into it, and open it in a browser as a real web page. This is the moment it stops being theoretical.

What you're actually about to do

Here is the whole job, and it does not get more complicated than this — only more detailed. You will write text with labels wrapped around it. The browser reads the labels and decides what everything is. That's HTML. There is no third step.

By the end of the module you'll have a page with your name on it — the index.html you created in VS Code in Module 0.4, inside your portfolio folder — open in a Live Preview that updates as you type.

The anatomy of a tag

A tag is a label you wrap around content to say what it is. It comes in a pair — one to open, one to close — and the closing one is the same word with a slash. Click each part below.

<p class="intro">Welcome to my page.</p>

A few tags don't wrap anything

Most elements surround content. A handful just are — an image, a horizontal rule, a line break. They have no closing tag because there's nothing inside them to close.

The skeleton every page has

Every HTML document on the internet starts the same way. You will type this so many times that VS Code has a shortcut for it — but type it by hand today, once, so the parts mean something.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport"
    content="width=device-width, initial-scale=1.0">
  <title>My first page</title>
</head>
<body>

  <h1>Hello, world</h1>

</body>
</html>

Nesting: boxes inside boxes

Elements go inside other elements, and the rule is the same as parentheses in arithmetic: whatever you opened last, you close first. Overlap them and you get a page that renders in ways nobody intended.

<p>This is <strong>important</strong> news.</p>

<p>This is <strong>important</p> news.</strong>

Indentation is how professionals keep this straight — every level of nesting moves two spaces to the right, so the structure is visible at a glance. The browser doesn't care; humans do, and you will be a human reading your own code next Tuesday. This is also exactly what Prettier does for you automatically, from Module 0.4.

Build it here first

Below is the skeleton, live. Type on the left; the page rebuilds on the right, and the fake browser tab shows your <title>. Four small challenges tick themselves off as you get them right. Nothing can break — it's your copy.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My first page</title>
</head>
<body>
  <h1>Hello, world</h1>
</body>
</html>

Comments: notes to humans

Anything between <!-- and --> is ignored by the browser. Use it to label sections of a long page, or to switch a chunk of HTML off temporarily while you test something — the same move as Ctrl/Cmd + / from Module 0.4.

<!-- Contact section starts here -->
<h2>Get in touch</h2>

One warning: comments are invisible on the page but perfectly visible to anyone who views the source. Never put a password, an internal note about a client, or anything you wouldn't say out loud into a comment.

Three things beginners get wrong

1. Forgetting the closing tag. On most elements, the element then swallows everything after it, and the page looks bizarre in a way that seems unrelated to what you typed. When something goes strange from a certain point downward, look for an unclosed tag just above that point.

2. Expecting Enter and the spacebar to lay things out. They don't, as you just saw. Spacing, columns and gaps are CSS, and that's Phase 2.

3. Saving the file wrong. If your browser shows you the code as text instead of a page, the file isn't really .html — it's index.html.txt. Module 0.3 told you to turn file extensions on; this is the day it pays off.

Words you now own

tag

The label itself: <p> opens, </p> closes.

element

The whole thing — opening tag, content, closing tag.

attribute

Extra detail on an opening tag, as name="value".

void element

An element with no content and no closing tag: <img>, <br>, <hr>.

nesting

Elements inside elements. Close them in the reverse order you opened them.

doctype

The first line, telling the browser to use modern standards.

head

Information about the page. Invisible to visitors.

body

Everything visitors see.

boilerplate

The standard skeleton you start every page with.

Emmet

VS Code's built-in shorthand. ! then Tab writes the skeleton.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport"
    content="width=device-width, initial-scale=1.0">
  <title>Maria Lopez</title>
</head>
<body>
  <h1>Maria Lopez</h1>
  <p>
    I'm learning to build websites so I can make one for my
    family's bakery.
  </p>
</body>
</html>

Plate 1.2 · Phase 1 — Framing · 20 minutes

Text: headings, paragraphs and lists

Ninety percent of what is on the web is written text. This module is about marking it up so that a reader, a screen reader and a search engine all understand the same shape — and it hinges on one idea most beginners never get told.

Headings are an outline, not a font size

Open the front page of the New York Times. There is one banner headline. Beneath it, section headings. Beneath those, subheads on individual stories. Nobody printed two equal-sized banner headlines on one page, and nobody chose a headline's size by deciding it "looked about right" — the size follows from the rank.

HTML works exactly the same way. <h1> through <h6> are ranks in an outline. They happen to come with default sizes attached, and that coincidence is what ruins beginners: they pick <h4> because <h2> looked too big, and the page's outline silently turns to nonsense.

The three rules

• One <h1> per page. It is the title of the content — what the page is, in one line. (HTML won't stop you writing two; this is the convention every accessibility guide recommends, and the one to follow. Accessibility means making a page usable by everyone, including people who hear it through a screen reader or navigate with only a keyboard.)
• Don't skip levels on the way down. An <h2> may be followed by an <h3>, not an <h4>. Coming back up, jumping any distance is fine.
• Never choose a heading by how it looks. If it's too big, that's a CSS problem, and you'll fix it in twenty seconds in Phase 2.

Check an outline the way a screen reader does

Below is markup from a real-looking coffee shop page, written by someone choosing headings by size. Edit the left side; the outline and its problems appear on the right. Fix the warnings, then read the corrected version.

Paragraphs, and the mistake everyone makes first

A paragraph is <p>…</p>. That's the whole story. But because Module 1.1 taught you that pressing Enter does nothing, there is a powerful temptation to reach for <br> — the line break — to separate blocks of text. Don't.

<p>We roast on Tuesdays.</p>
<p>Orders ship on Thursdays.</p>

<p>We roast on Tuesdays.<br><br>
Orders ship on Thursdays.</p>

<br> has exactly one honest use: a line break within a single block of text where the break is part of the content. A postal address, a line of a poem, a song lyric. If the break is decorative or is really separating two ideas, you want two elements instead.

Words that carry meaning

Some inline elements exist to say what a piece of text is, not what it should look like. The pairs below look identical on screen but carry different meaning — to search engines, to translation and reading tools, and to the next developer. (Most screen readers read them in the same voice by default, so don't rely on them for spoken emphasis.)

The honest summary: use <strong> and <em> by default, because nearly every time you want bold or italic you also mean importance or emphasis. Keep <b> and <i> for the narrow cases where you truly mean "different, but no more important."

Lists: three kinds, and choosing between them

If content reads like a list, mark it as a list. A screen reader announces "list, five items" and lets the user skip it — a service you get free, and lose entirely if you fake a list with dashes and line breaks.

Inside <ul> and <ol>, the only thing allowed as a direct child is <li>. Anything else goes inside an <li>. That single rule is behind the most common list bug there is:

<ul>
  <li>Espresso
    <ul>
      <li>Single</li>
      <li>Double</li>
    </ul>
  </li>
  <li>Filter</li>
</ul>

<ul>
  <li>Espresso</li>
  <ul>
    <li>Single</li>
  </ul>
  <li>Filter</li>
</ul>

Two attributes worth knowing on <ol>: start="5" begins the numbering somewhere other than 1 — useful when a list continues after an interruption — and reversed counts down, for a countdown of finalists.

Which list is it?

Six pieces of content. Decide before you click.

Characters that need escaping

Three characters mean something to HTML, so writing them literally can confuse the browser. Write these instead:

These are called entities. There are hundreds; you will use these four and look up the rest when you need them.

Three things beginners get wrong

1. Choosing a heading level by its size. The whole module in one sentence. Rank first, size later.

2. Using <br><br> where two paragraphs belong. Identical on screen, structurally false, and impossible to space properly later.

3. Writing lists as plain text with dashes. "- Espresso" typed into a paragraph is not a list to anything except a sighted reader. One minute of markup buys you announcement, navigation and styling.

Words you now own

heading level

The rank of a heading, h1 through h6.

document outline

The structure your headings create — what screen readers and search engines navigate.

semantic

Markup chosen for what content means rather than how it looks.

block element

Starts on a new line and fills the width: <p>, <h2>, <ul>.

inline element

Sits within a line of text: <strong>, <em>, <code>.

unordered list

<ul> — order doesn't matter.

ordered list

<ol> — order is the information.

description list

<dl> with <dt> terms and <dd> descriptions.

entity

A code like & standing in for a character HTML would otherwise misread.

<h1>Maria Lopez</h1>
<p>I'm learning web development, one module at a time.</p>

<h2>What I'm learning</h2>
<ol>
  <li>Ground Floor</li>
  <li>HTML</li>
  <li>CSS</li>
  <!-- …and so on -->
</ol>
<p>
  <strong>I practice every weekday.</strong> It's the
  <em>habit</em> that matters, not the hours.
</p>

<blockquote>
  <p>The best way to predict the future is to invent it.</p>
</blockquote>
<p>— Alan Kay</p>

<h2>How to reach me</h2>
<ul>
  <li>Email</li>
  <li>LinkedIn</li>
  <li>GitHub</li>
</ul>

h1  Maria Lopez
  h2  What I'm learning
  h2  How to reach me

Plate 1.3 · Phase 1 — Framing · 20 minutes

Links: the thing that makes it a web

A page on its own is a document. Pages that point at each other are a web — that's where the name comes from. This module is about one element, <a>, which is arguably the single most important invention in the history of the internet.

Why this one element matters so much

In 1989, at CERN outside Geneva, Tim Berners-Lee had a practical problem: thousands of physicists writing documents on different computers, and no way to get from one to another. His proposal was simple. Let any document point at any other document, anywhere, with one click. He called the pointers hypertext links, and the network of documents they created a World Wide Web.

Every other invention in this manual — CSS, JavaScript, the whole of Phase 7 — was built on top of that one idea. You are about to learn the element that implements it.

The anatomy of a link

<a href="https://www.nps.gov/yell/">
  Yellowstone National Park
</a>

The a stands for anchor — a historical name nobody uses in conversation. Everyone just says "link".

Five places a link can point

The href can hold five quite different kinds of destination. Pick one below, change the fields, and the correct markup writes itself — along with what happens when someone clicks it, and anything you've done that a professional would flag.

Two of those are worth underlining. Another site must start with https:// — leave it off and the browser assumes you mean a file inside your own project, exactly the relative-path rule from Module 0.3. And Phone links are one of the most valuable lines you can put on a small business's site: on a phone, a tap dials the number. Every restaurant, plumber and dentist should have one.

Same-page links: a table of contents in two halves

A jump link needs two things that match: an id on the place you're jumping to, and a link whose href is that id with a # in front. You've seen the # before — it's the fragment from the URL anatomy in Module 0.1, the one part of an address that never leaves your browser.

<!-- the link, near the top -->
<a href="#hours">Opening hours</a>

<!-- the destination, further down -->
<h2 id="hours">Opening hours</h2>

Two rules for id: it must be unique on the page — two elements can't share one, any more than two houses on one street can share a number — and it should follow the filename rules from Module 0.3: lowercase, hyphens, no spaces.

The link text is the whole game

Remember from Module 1.2 that screen reader users can pull up a list of every heading on a page? They can do exactly the same with links. Now picture that list on a typical small-business site:

click here
click here
read more
read more
read more
here
link

fall menu
catering inquiries
our Portland roastery
wholesale pricing (PDF, 2 MB)
directions to the Pearl District shop
opening hours
contact us

Rewrite it

Four real link patterns. In each option, the underlined words are the link. Pick the best version of each.

New tabs: almost never

Adding target="_blank" makes a link open in a new tab. Beginners love it for external links — "so they don't leave my site". Resist it.

Opening a new tab takes a decision away from the visitor, breaks their Back button, and disorients anyone using a screen reader or a phone, where a new tab can be nearly invisible. People who want a new tab already know how to get one: middle-click, or Ctrl/Cmd + click. Let them choose.

The honest exceptions are narrow: a help link in the middle of a half-filled form, where leaving the page would lose their work; or a PDF they'll want open alongside the page. When you do use it, say so in the link text — "Size guide (opens in new tab)" — so nobody is surprised.

You will often see rel="noopener" written alongside target="_blank". It stops the new page from reaching back and tampering with yours. Modern browsers now apply it by default, but writing it is harmless and still common in professional code.

A link goes somewhere. A button does something.

One distinction that separates professionals from everyone else, and that you'll lean on for the rest of the manual:

• Use <a> when clicking takes you to a different place — another page, another site, a section further down. It gets a URL; it can be bookmarked, shared, opened in a new tab.
• Use <button> when clicking makes something happen here — submit a form, open a menu, add to cart, play a video. That's JavaScript's territory, from Phase 4.

Using a link as a button, or a button as a link, looks identical on screen and breaks keyboard users, screen readers and the browser's own features in quietly infuriating ways.

Navigation is a list of links

The bar of links across the top of almost every website is, structurally, just the list you learned in Module 1.2 — wrapped in an element that announces "this is the site's navigation":

<nav>
  <ul>
    <li><a href="index.html" aria-current="page">Home</a></li>
    <li><a href="menu.html">Menu</a></li>
    <li><a href="locations.html">Locations</a></li>
  </ul>
</nav>

aria-current="page" marks the link to the page you're already on, so a screen reader announces "current page" — and in Phase 2 you'll use it to underline or highlight the active item. You'll learn <nav> and its relatives properly in Module 1.5; for now, recognize the shape.

Three things beginners get wrong

1. "Click here." The most common link text on the internet, and the least useful. The words should name the destination.

2. Forgetting https:// on external links. <a href="www.nps.gov"> looks right, and sends people to yoursite.com/www.nps.gov — a file that doesn't exist. Every link to another site starts with https://.

3. Opening everything in a new tab. It feels like keeping visitors; it actually takes control from them. Default to the same tab.

Words you now own

hyperlink

A clickable reference from one document to another. Just "link" in conversation.

<a> — anchor

The HTML element that makes a link.

href

The attribute holding the destination.

link text

What's between the tags: what people read, click and hear.

absolute URL

A full address starting with https://. Needed for any other site.

id

A unique name on an element, so a link can jump to it with #.

mailto: / tel:

Links that open an email draft or dial a phone number.

target="_blank"

Opens the link in a new tab. Use rarely, and say so.

aria-current

Marks the link to the page you're already on.

<nav>
  <ul>
    <!-- on index.html -->
    <li><a href="index.html" aria-current="page">Home</a></li>
    <li><a href="about.html">About</a></li>
  </ul>
</nav>

<p>
  <a href="#learning">What I'm learning</a> ·
  <a href="#contact">How to reach me</a>
</p>
…
<h2 id="learning">What I'm learning</h2>
…
<h2 id="contact">How to reach me</h2>

<a href="https://developer.mozilla.org/">MDN Web Docs</a>
<a
  href="mailto:maria@example.com?
  subject=Hello%20from%20your%20site">
  Email me
</a>

Plate 1.4 · Phase 1 — Framing · 25 minutes

Images, video and file paths

Pictures make a page feel alive, and they are also the single heaviest thing on almost every website. This module is about putting media on a page so it loads fast, never shows up broken, and still makes sense to someone who can't see it.

Why images deserve a whole module

Go back to the Network tab exercise from Module 0.4 and sort by size: on nearly every site, the heaviest files are images. A single photo straight off an iPhone is 3–5 MB — more than the entire HTML, CSS and JavaScript of most pages combined. Get images wrong and your site is slow, broken, or silent to blind visitors. Get them right and none of that happens, for about two minutes of extra work per image.

The image element

<img src="images/rainier.jpg"
     alt="Mount Rainier at sunrise,
         snow-covered above a pine forest"
     width="1600" height="900">

A void element — no closing tag, as you learned in 1.1 — with four attributes that each do a real job:

Alt text: the museum label read aloud

At the Louvre, a guide walking a blind visitor through the galleries doesn't say "a painting, oil, 77 by 53 centimeters." They say what matters: a woman with a faint smile, hands folded, a winding landscape behind her. They describe what the image is for in that room. That is exactly the job of alt.

Alt text is also what appears when the image fails to load — slow connection, wrong path, blocked file. Try it:

One image, with and without its file Break the path

<img src="images/rainier.webp"
     alt="Mount Rainier at sunrise,
         snow-covered above a pine forest"
     width="480" height="270">

The four rules of alt text

• Describe the purpose, not just the pixels. A photo of a Boston clam chowder on a menu page: "New England clam chowder in a bread bowl." On a page about bread bowls: "A sourdough bread bowl, hollowed and filled with chowder." Same photo, different job.
• Never start with "image of" or "picture of". The screen reader already announces it's an image.
• Decorative images get an empty alt: alt="". A flourish, a background texture, a divider. Empty tells a screen reader to skip it. Missing alt makes it read the filename — the worst of both.
• If an image is a link, describe where it goes. A logo linking home: alt="Cedar & Pine Coffee — home", not "logo".

Write better alt text

Choosing a file format

Size: the one habit that makes sites fast

Resize before you upload. An iPhone photo is around 4000 pixels wide. The widest your content area will ever be is roughly 1200–1600. Everything beyond that is downloaded, decoded, and thrown away — on every visit, by every visitor.

Free tools do this in seconds: Squoosh (squoosh.app, from Google, runs in your browser — it resizes and converts to WebP), or Preview on a Mac (Tools → Adjust Size) for resizing. Make it a reflex: resize, compress, then upload.

Later you'll go further: <picture> lets you offer a modern format with a fallback, and srcset lets a phone download a smaller version than a desktop (Module 8.2 covers both). A preview of the shape:

<picture>
  <source srcset="images/rainier.avif" type="image/avif">
  <img src="images/rainier.jpg"
    alt="Mount Rainier at sunrise…"
    width="1600" height="900">
</picture>

One more free speed win: add loading="lazy" to images further down the page. The browser then only fetches them as the visitor scrolls near. Don't use it on the first image people see — that one should load immediately.

Images with captions

When an image needs a visible caption — a credit, a date, an explanation — wrap both in <figure>, and the caption in <figcaption>. That ties them together for assistive technology rather than leaving a loose paragraph that merely happens to sit nearby.

<figure>
  <img src="images/golden-gate.webp"
    alt="The Golden Gate Bridge in fog, towers just visible"
       width="1600" height="900" loading="lazy">
  <figcaption>
    San Francisco, July — photo by Dana Whitfield.
  </figcaption>
</figure>

Alt and caption do different jobs: alt replaces the image for people who can't see it; the caption adds information for everybody. Don't copy one into the other.

Video and audio

<video controls width="1280" height="720"
  poster="images/roastery-poster.webp">
  <source src="media/roastery.mp4" type="video/mp4">
  <track kind="captions" src="media/roastery-en.vtt"
    srclang="en" label="English">
  Your browser can't play this video.
  <a href="media/roastery.mp4">Download it instead</a>.
</video>

• controls shows play, pause, volume and full-screen. Without it, people can't operate the video at all.
• poster is the still image shown before playback — otherwise it's often a black rectangle.
• <track kind="captions"> adds subtitles. Deaf visitors need them, and so does everyone watching on a train with the sound off — most social video is watched muted.
• Never autoplay with sound. Browsers block it anyway. A silent background loop is allowed: autoplay muted loop playsinline — but anything that moves for more than five seconds needs a way to pause it (an accessibility rule, WCAG 2.2.2), so keep controls or keep the loop short.

<audio controls> works exactly the same way, for podcasts and music.

Three things beginners get wrong

1. Leaving out alt. Blind visitors hear filenames, and Google has nothing to go on. Every <img> gets an alt — descriptive, or empty if decorative. Never missing.

2. Uploading photos straight from the phone. Four megabytes each, ten per page, and a site that crawls on mobile data. Resize and compress first, every time.

3. Paths and capitals. Images/Photo.JPG works on your laptop and breaks live. It's Module 0.3 again — and it's the most common broken image on the internet.

Words you now own

src

The path to the media file.

alt text

The text replacement for an image, read by screen readers and shown when it fails.

decorative image

One that adds nothing to meaning. Gets alt="".

layout shift

Content jumping as images load. Prevented with width and height.

WebP / AVIF

Modern formats, much smaller than JPEG for the same quality.

SVG

A vector format for logos and icons — sharp at any size.

lazy loading

Fetching an image only as the visitor scrolls near it.

figure / figcaption

An image and its visible caption, bound together.

poster

The still image shown before a video plays.

captions track

A .vtt subtitle file attached with <track>.

<img src="images/maria-hiking.webp"
     alt="Maria on the summit trail at Mount Tamalpais,
         smiling at the camera"
     width="800" height="600">

<figure>
  <img src="images/first-website-sketch.webp"
       alt="A pencil sketch of my site's home page layout"
       width="800" height="1000" loading="lazy">
  <figcaption>
    My first sketch of this site, drawn before writing any code.
  </figcaption>
</figure>

Plate 1.5 · Phase 1 — Framing · 25 minutes

Semantic HTML: naming rooms, not just building them

You can build a whole page out of anonymous boxes, and it will look fine. This module is about the handful of elements that say what each region of a page is — the difference between amateur markup and professional markup, and one of the cheapest accessibility and search wins there is.

A floor plan with labels

Picture a realtor's floor plan for a Chicago apartment. Every room is labeled: Kitchen, Living room, Bedroom 1, Bath. Now picture the same plan with every room labeled Room. Same walls, same square footage — and suddenly useless to anyone trying to find the bathroom in the dark.

That's the difference between these two pages. They render identically.

<div class="top">
  <div class="menu">…</div>
</div>
<div class="content">
  <div class="post">…</div>
</div>
<div class="bottom">…</div>

<header>
  <nav>…</nav>
</header>
<main>
  <article>…</article>
</main>
<footer>…</footer>

What a screen reader actually gets

Screen readers offer a list of landmarks — the named regions of a page — so users can jump straight to the navigation or the main content, the way you'd follow signs at O'Hare to Baggage Claim instead of walking every corridor. Semantic elements create those signs automatically. Switch between the two versions:

<div class="top">
  <div class="logo">Cedar &amp; Pine</div>
  <div class="menu">...links...</div>
</div>
<div class="content">
  <div class="post">...</div>
  <div class="sidebar">...</div>
</div>
<div class="bottom">...</div>

<header>
  <a href="/">Cedar &amp; Pine</a>
  <nav aria-label="Main">...links...</nav>
</header>
<main>
  <article>...</article>
  <aside>...</aside>
</main>
<footer>...</footer>

The elements, and what each one means

article or section? The one people argue about

Ask one question: would this make sense if it were lifted out and published somewhere else on its own?

• A recipe for Philadelphia cheesesteak, with its title, ingredients and method — yes, it stands alone. <article>.
• The "Ingredients" part of that recipe — no, it only makes sense inside the recipe. <section>.

Articles can contain sections, and sections can contain articles — a "Latest posts" section holding five article cards is completely normal.

The skeleton of nearly every website

<body>
  <a class="skip" href="#main">Skip to main content</a>

  <header>
    <a href="index.html">Cedar &amp; Pine Coffee</a>
    <nav aria-label="Main">
      <ul>…</ul>
    </nav>
  </header>

  <main id="main">
    <h1>Fresh roasted in Portland</h1>
    <section> <h2>Our story</h2> … </section>
    <section> <h2>Visit us</h2> … </section>
  </main>

  <footer>
    <address>1200 NW Everett St, Portland, OR</address>
    <p>&copy; 2026 Cedar &amp; Pine Coffee</p>
  </footer>
</body>

Two details worth copying. The skip link at the very top lets keyboard users jump past the header straight to the content instead of tabbing through every menu item on every page — in Phase 2 you'll hide it until it receives focus. And aria-label="Main" names the nav, which matters when a page has more than one.

Which element is it?

Why it's worth the effort

• Accessibility: landmarks and skip links make a page navigable without sight or a mouse — in the US, inaccessible sites are a real source of lawsuits under the ADA.
• Search: clear structure helps search engines tell the page's real content from the menus and footers repeated everywhere — it can only help, never hurt.
• Browser features: reader modes (Safari Reader, Firefox Reader View) use these elements to find the real content.
• Your future self: </main> tells you where you are in a 400-line file. </div> tells you nothing.

Three things beginners get wrong

1. Div soup. Every region a <div class="…">. It works, and it throws away everything this module describes.

2. More than one <main>. One page, one main — like one h1.

3. <section> as a styling wrapper. If it has no heading and no theme, it's a div.

Words you now own

semantic element

One whose name says what its content is.

div soup

A page built entirely from meaningless divs.

landmark

A named region a screen reader can jump to: header, nav, main, footer…

<main>

The unique content of the page. One per page.

<article>

Content that stands on its own.

<section>

A themed part with its own heading.

<aside>

Related but secondary content.

skip link

A link at the top that jumps keyboard users to the main content.

div / span

Meaning-free containers for styling, block and inline.

<body>
  <a href="#main">Skip to main content</a>
  <header>
    <p><a href="index.html">Maria Lopez</a></p>
    <nav> …your two links… </nav>
  </header>

  <main id="main">
    <h1>Maria Lopez</h1>
    <section>
      <h2 id="learning">What I'm learning</h2> …
    </section>
    <section> <h2 id="contact">How to reach me</h2> … </section>
  </main>

  <footer>
    <p>
      &copy; 2026 Maria Lopez ·
      <a href="mailto:maria@example.com">Email me</a>
    </p>
  </footer>
</body>

Plate 1.6 · Phase 1 — Framing · 30 minutes

Forms: how users talk back

Everything so far has been one-way: you publish, people read. Forms are the moment the conversation reverses — a search box, a sign-up, a booking, a checkout. Every web app you'll ever build is, underneath, a set of forms.

The paper form at the DMV

Think of a form at a Department of Motor Vehicles office. Each box has its label printed right beside it. Required fields are marked. The clerk at the window glances over it and hands it back if you left the date blank — and then, after you've gone, someone in the back office checks everything again properly before anything is issued.

The anatomy of a form

<form action="/inquiry" method="post">
  <label for="name">Your name</label>
  <input id="name" name="name" type="text"
    autocomplete="name" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email"
    autocomplete="email" required>

  <button type="submit">Send inquiry</button>
</form>

Notice that id and name do different jobs even though they often hold the same word: id connects the label on this page; name labels the data when it leaves.

GET or POST: a postcard or an envelope

• GET writes the answers into the URL itself: /search?q=hiking+boots&size=10. Like a postcard — anyone handling it can read it. Perfect for searches and filters, because the result can be bookmarked and shared. Never for anything private.
• POST puts the answers inside the request, out of the address bar and browser history. Like an envelope. Use it for anything that creates, changes or is private: sign-ups, logins, orders, messages.

One honest caveat: an envelope keeps the answers out of sight, but it isn't a lock. What actually seals the envelope — so nobody along the way can read it — is HTTPS, from Module 0.1. Private data needs both: POST and HTTPS.

Fill it in and see what gets sent

This is a real form with real browser validation. Try submitting it empty, or with a bad email. When it's valid, you'll see exactly what would leave your browser — then flip the options to see GET versus POST, and what happens when a field forgets its name.

Input types: the right box for the job

The type attribute changes the keyboard a phone shows, the picker a browser offers, and the checking it does for free. Pick one and try it — on a phone, the keyboard difference is dramatic.

<label for="x">Email</label>
<input id="x" name="x" type="email" autocomplete="email">

Choices: checkboxes, radios and dropdowns

• Radio buttons — pick exactly one. Every radio in a group shares the same name; that's what makes them a group.
• Checkboxes — pick any number, including none.
• <select> — pick one from a long list, like a US state. Under about six options, radios are friendlier because every choice is visible.

Wrap a group of radios or checkboxes in <fieldset> with a <legend>. The legend is the question — "Service", "Dietary needs" — and a screen reader announces it before each option, so "Drop-off" isn't heard with no idea what it's an answer to.

<label for="state">State</label>
<select id="state" name="state" autocomplete="address-level1">
  <option value="">Choose…</option>
  <option value="OR">Oregon</option>
  <option value="WA">Washington</option>
</select>

Validation you get for free

Your contact form, in full

Here's the markup for the build below, with the three pieces you haven't seen written out yet: a <textarea> for a longer message, minlength, and a radio group. Each radio needs the same name and its own value — without a value, the form sends the useless word "on".

<label for="message">Message</label>
<textarea id="message" name="message" rows="5"
  minlength="20" required></textarea>

<fieldset>
  <legend>How did you hear about me?</legend>
  <label>
    <input type="radio" name="source"
      value="friend"> A friend
  </label>
  <label>
    <input type="radio" name="source"
      value="linkedin"> LinkedIn
  </label>
  <label>
    <input type="radio" name="source"
      value="search"> A search engine
  </label>
</fieldset>

Wrapping the radio inside its <label> is the other way to connect them — no for and id needed.

Where does the data go before you have a server?

Until Phase 7 you have no backend of your own. For a static site's contact form, form services fill the gap: Formspree gives you an address to put in action and emails you each submission; Netlify Forms does the same once your site is hosted on Netlify (Module 5.6), by adding one attribute to the form. Free for low volumes, and perfectly professional for a small business site.

Three things beginners get wrong

1. Placeholder instead of label. Gray hint text inside a box vanishes the moment someone types, is usually too faint to read comfortably, and isn't a reliable name for the field. Use a real <label>; a placeholder can add an example, never replace the label.

2. Forgetting name. The form looks perfect, submits happily, and that field never arrives. You just saw it happen above.

3. Asking for too much. Every extra field loses people. If you won't use their phone number, don't ask for it.

Words you now own

form

The container that gathers fields and sends them.

action / method

Where the data goes, and how — GET or POST.

label

The visible, announced name of a field.

name

The key a field's value is sent under.

fieldset / legend

A group of related fields and the question they answer.

client-side validation

Checking in the browser, for convenience.

server-side validation

Checking on the server, for real.

autocomplete

Hints that let the browser fill saved details.

<main id="main">
  <h1>Contact me</h1>
  <form action="https://formspree.io/f/your-id" method="post">
    <label for="name">Your name</label>
    <input id="name" name="name" type="text"
      autocomplete="name" required>

    <label for="email">Email</label>
    <input id="email" name="email" type="email"
      autocomplete="email" required>

    <label for="message">Message</label>
    <textarea id="message" name="message" rows="5"
      minlength="20" required></textarea>

    <fieldset>
      <legend>How did you hear about me?</legend>
      <label>
        <input type="radio" name="source"
          value="friend"> A friend
      </label>
      <label>
        <input type="radio" name="source"
          value="linkedin"> LinkedIn
      </label>
    </fieldset>

    <button type="submit">Send message</button>
  </form>
</main>

Plate 1.7 · Phase 1 — Framing · 15 minutes

Tables, and when not to use them

A short module about an element with a strange history. Tables are exactly right for one job — data in rows and columns — and for about ten years in the 1990s and 2000s, the whole web misused them for something else entirely.

The one job tables do

Open the sports section and look at the NFL standings, or look at an Amtrak timetable from Boston to Washington. Every value only means something because of two things: the row it's in and the column it's in. "7" means nothing. "Wins, Philadelphia Eagles: 7" means everything.

The anatomy of a table

<table>
  <caption>Forecast highs, first week of October (°F)</caption>
  <thead>
    <tr>
      <th scope="col">City</th>
      <th scope="col">Mon</th>
      <th scope="col">Tue</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Chicago</th>
      <td>64</td>
      <td>59</td>
    </tr>
  </tbody>
</table>

Why the headings matter: listen to a cell

A sighted reader glances up and across to find a cell's meaning. A screen reader user can't — so the screen reader does it for them, reading out the row and column headings with each value. But only if those headings are marked as headings. Click any number, then switch the headings off.

Table, or not a table?

The history lesson: layout tables

Before CSS could arrange a page properly, designers in the late 1990s discovered they could force a two-column layout by building the entire page as one giant invisible table — navigation in the left cell, content in the right. Much of the early web, from news sites to Fortune 500 homepages, was built this way.

It worked visually and was a disaster underneath: screen readers announced "table, 3 columns, 14 rows" for a homepage, content read out in nonsensical order, and nothing adapted to phones. Today layout belongs entirely to CSS — Flexbox and Grid, Modules 2.5 and 2.6. A table is for data, never for arranging a page. If you ever inherit an old site built with layout tables, now you'll recognize it.

Three things beginners get wrong

1. Headings as <td> in bold. It looks the same and loses all the meaning — as you just heard.

2. Tables for layout. Two columns of content side by side is a layout job. That's CSS.

3. No caption. Without it, nobody knows what the numbers are before they start reading them.

Words you now own

<tr>

A table row.

<th>

A header cell, with scope saying whether it heads a column or a row.

<td>

A data cell.

<caption>

The table's title.

thead / tbody / tfoot

Header rows, data rows, summary rows.

colspan / rowspan

A cell spanning several columns or rows.

layout table

The old, wrong practice of arranging a page with a table.

<table>
  <caption>My learning plan</caption>
  <thead>
    <tr>
      <th scope="col">Phase</th>
      <th scope="col">Topic</th>
      <th scope="col">Target finish</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">1</th>
      <td>HTML</td>
      <td><time datetime="2026-10-15">October 15</time></td>
    </tr>
    <!-- one <tr> per phase -->
  </tbody>
</table>

Plate 1.8 · Phase 1 — Framing · 25 minutes · Final module of Phase 1

Accessibility: ramps, not just stairs

You've been building accessibly for seven modules without it having its own name. This module names it, fills the gaps HTML alone can't cover, and teaches you to test it — because a site that only works for some people only half works.

The curb cut

In the early 1970s, disability activists in Berkeley, California, pushed the city to cut ramps into its sidewalk curbs so wheelchair users could cross the street. The cuts were built for them. Then something nobody predicted happened: everyone started using them. Parents with strollers. Travelers with rolling suitcases. Delivery workers with hand trucks. Cyclists. Today every sidewalk in America has them, and almost nobody thinks of them as a disability feature.

That is the curb-cut effect, and it's the best argument for accessibility on the web. Captions were added for deaf viewers — now most social video is watched with the sound off. Keyboard navigation was built for people who can't use a mouse — power users rely on it daily. Good contrast was for low vision — it's also what makes a phone readable in bright sunshine at a Miami beach.

Who you're building for

Roughly one in four US adults has some form of disability, according to the CDC. But disability isn't only permanent. Microsoft's inclusive design team frames it three ways, and it changes how you think:

Build for the left column and you've built for everybody in the other two — which, at some point, is everyone, including you.

It's also the law

In the US, courts regularly treat business websites as covered by the Americans with Disabilities Act, and thousands of web accessibility lawsuits are filed every year — many against small businesses. In the EU, the European Accessibility Act has applied since June 2025, requiring many consumer-facing websites and apps to be accessible. The shared technical standard behind both is WCAG — the Web Content Accessibility Guidelines. Most laws and contracts currently point to WCAG 2.1 level AA; the newer 2.2 (2023) adds a few requirements on top. Build to 2.2 AA and you meet both.

What you've already done

Here's Phase 1 again, seen through this lens. Every one of these was an accessibility lesson:

That's most of it. Correct HTML is roughly 70% of accessibility, for free. The rest of this module covers what's left.

The keyboard test

Many people never touch a mouse: people with tremors or paralysis, blind users, and anyone who simply works faster from the keyboard. Everything clickable must be reachable with Tab and usable from the keyboard — Enter follows a link or presses a button; Space also presses buttons and ticks checkboxes. Real elements — <a>, <button>, <input> — do this automatically. A <div> made clickable with JavaScript does not.

Click inside the box below, then press Tab repeatedly and watch the orange ring move.

"Order online" looks exactly like a button, and the Tab key sails straight past it. For a keyboard user, that feature doesn't exist. It's one of the most damaging accessibility failures on the web — and the fix is simply to use <button>.

And never remove the focus ring with CSS to "clean up" a design. That ring is a keyboard user's cursor. Style it to match your brand in Phase 2 — don't delete it.

Color contrast

Light gray text on white looks elegant in a design mockup and is unreadable for people with low vision, older eyes, cheap screens and anyone outdoors. It's also the most common failure of all: WebAIM's yearly scan of a million home pages finds low-contrast text on the large majority of them. WCAG sets minimum contrast ratios: 4.5 : 1 for normal text, 3 : 1 for large text (about 24px, or 19px bold). Try it:

And one related rule: never use color as the only signal. "Required fields are in red" fails the roughly 1 in 12 men with color-blindness. Add a word or a symbol too — "Required", an asterisk, an icon.

The rest of the short list

• Zoom: the page must still work at 200% zoom. Try Ctrl/Cmd + + on your own site.
• Motion: animations can cause real nausea for people with vestibular disorders. Phase 2 teaches you to honor the "reduce motion" setting.
• Plain language: short sentences and familiar words help people with cognitive disabilities, non-native speakers, and people in a hurry — which is everyone.
• Target size (new in WCAG 2.2): anything you tap should be at least 24 × 24 pixels, or have that much space around it. Tiny icons packed together fail.
• Focus not hidden (also 2.2): a sticky header must never cover the element that has keyboard focus.
• ARIA: attributes like aria-label and aria-current patch gaps HTML can't fill. The first rule of ARIA, written by the people who made it: don't use ARIA if a native HTML element will do the job.

How to test, in ten minutes

1. Unplug the mouse. Tab through the whole page. Can you reach and use everything? Can you always see where you are?
2. Run Lighthouse (DevTools, Module 0.4) with the Accessibility box ticked. It catches missing alt, low contrast, missing labels. Aim for 100 — but know it only catches about a third of real problems.
3. Listen to it. On a Mac, Cmd + F5 turns VoiceOver on and off (on some keyboards, Cmd + Fn + F5). On Windows, Narrator is built in — Ctrl + Win + Enter — and NVDA is a free download. Close your eyes for one minute and try to find the contact form.
4. Zoom to 200% and check nothing overlaps or disappears.

Three things beginners get wrong

1. Treating it as a final checkbox. Retrofitting accessibility is expensive; building it in from the first line — as you have been — costs almost nothing.

2. Clickable divs. They look like buttons and aren't. Use the real element.

3. Trusting the score. Lighthouse at 100 doesn't mean accessible. Only a keyboard and a screen reader tell you the truth.

Words you now own

accessibility (a11y)

Making sites work for people of all abilities. "a11y" = a, 11 letters, y.

WCAG

The international standard. Level AA is the usual target.

curb-cut effect

Features built for disabled people that end up helping everyone.

focus

Which element the keyboard is currently on.

focus ring

The visible outline showing focus. Never remove it.

contrast ratio

Lightness difference between text and background. 4.5 : 1 minimum for body text.

screen reader

Software that reads a page aloud: VoiceOver, NVDA, JAWS.

ARIA

Attributes that patch gaps in HTML. Native elements first.

Plate 2.1 · Phase 2 — Finishes · 25 minutes · First module of Phase 2

How CSS attaches to HTML: selectors

Phase 1 built the house. Phase 2 paints it. Before a single color goes on a wall, you need to know how to point at the wall you mean — and why, sometimes, the paint you applied doesn't show up. That's this module.

A rule is a memo with an addressee

Every line of CSS you will ever write is a rule, and every rule has the same two halves: who it applies to, and what to do.

h1 {
  color: navy;
  font-size: 40px;
}

Where CSS lives

There are three places you can write it. Professionals use the third almost exclusively.

• Inline — <p style="color: red">. One element at a time. Impossible to maintain across a site; you used it once in Module 0.1 and that's enough.
• A <style> block in the <head>. Fine for a single page, but every page needs its own copy.
• An external stylesheet — css/styles.css, linked from every page with the line you met in Module 0.2: <link rel="stylesheet" href="css/styles.css">. One file styles the entire site. Change the brand color once; every page updates.

Pointing at things: the selectors

Think of a memo circulating at a company in Boston. It can be addressed to all staff, to everyone on the sales team, to one named person, or to sales staff working in the Chicago office. CSS selectors work exactly the same way.

A class is added in HTML with class="…" and can be used as often as you like — and one element can wear several: class="card featured". An id must be unique, as you learned in Module 1.3.

Try the selectors live

Type a selector. Everything it matches lights up orange, and you'll see the count. Try the examples, then invent your own.

<nav>
  <ul>
    <li><a href="#" class="active">Menu</a></li>
    <li><a href="#">Locations</a></li>
  </ul>
</nav>
<article id="special" class="card featured">
  <h3>Maple Latte</h3>
  <p class="price">$5.50</p>
  <p>Vermont maple, oat milk.</p>
</article>
<article class="card">
  <h3>Cold Brew</h3>
  <p class="price">$4.75</p>
  <p>Steeped 18 hours. <a href="#">Details</a></p>
</article>
<form>
  <input type="email" placeholder="Email">
  <input type="text" placeholder="Name">
</form>

When two rules disagree: the cascade

The C in CSS stands for cascading, and it answers the question beginners hit within an hour: "I wrote the rule, why isn't it working?" Usually, it is working — another rule is simply winning. When several rules target the same element, the browser decides in this order:

1. Importance first. A declaration marked !important beats normal ones. (Cascade layers, in Module 2.10, also sit at this level.) You'll almost never need either — see the warning below.
2. Specificity — the more precise address wins. A memo to one named person beats a memo to the sales team, which beats a memo to all staff. In CSS: an inline style="" attribute beats an id, which beats a class, which beats a type. #hero beats .title beats h1 — whatever order they're written in.
3. Order — if equally specific, the later rule wins. Two memos to the sales team: the most recent one stands.

Inheritance: only when nothing targets the element

Some properties — mostly text ones like color and font-family — flow down from parent to children. Set color on body and every paragraph inside inherits it. Box properties like border don't inherit; that would be chaos.

But inheritance is the weakest thing in the cascade: an inherited value loses to any rule that targets the element directly — including the browser's own built-in styles. That's why two things surprise everyone:

• body { color: #333; } does not recolor your links. The browser's built-in style targets a directly (that's where default link blue comes from), so you need an a { color: … } rule of your own.
• Buttons, inputs and textareas don't inherit your font. Add this line near the top of every stylesheet: button, input, select, textarea { font: inherit; }

Which color wins?

See the cascade in DevTools

Right-click any element, choose Inspect, and look at the Styles pane (Module 0.4). Every rule that matches is listed, most specific at the top. Declarations that lost are shown crossed out. When a style "isn't working", this pane tells you exactly which rule beat it and where that rule lives. Nine times in ten, that's the whole debugging session.

Three things beginners get wrong

1. A missing semicolon or brace. CSS fails silently: one missing ; and both that declaration and the next are ignored, with no error anywhere. Prettier and Error Lens from Module 0.4 catch most of these.

2. Forgetting the dot. price { } looks for an element called <price>, which doesn't exist. Classes need .price.

3. Fighting specificity with ids and !important. Each fix makes the next one harder. Use classes and keep selectors short.

Words you now own

rule

A selector plus a declaration block.

selector

The part that says which elements a rule applies to.

declaration

One property: value; pair.

class

A reusable label added in HTML; selected with a dot.

pseudo-class

A state, like :hover or :focus-visible.

cascade

The rules deciding which declaration wins.

specificity

How precise a selector is: id > class > type.

inheritance

Text properties flowing from parent to children — only when no rule targets the child directly.

!important

A forced win. An emergency measure, not a habit.

<link rel="stylesheet" href="css/styles.css">

body {
  font-family: Georgia, serif;
  color: #1b2321;
}
button, input, select, textarea { font: inherit; }

a { color: #0d6e6b; }
nav a { text-decoration: none; font-weight: 600; }
a:hover { text-decoration: underline; }
a:focus-visible {
  outline: 3px solid #c9731b;
  outline-offset: 2px;
}

/* <p class="intro"> in your HTML */
.intro { font-size: 1.25rem; }

Plate 2.2 · Phase 2 — Finishes · 25 minutes

The box model: every element is a shipping box

Here is the secret that makes CSS layout make sense: every single element on every web page is a rectangle. Headings, paragraphs, images, links — boxes. Once you know the four layers of a box, spacing stops being guesswork.

Shipping a painting

You're sending a framed print from a gallery in Santa Fe to a buyer in Brooklyn by UPS. It's packed in four layers, and each one does a different job.

Pull the layers yourself

Move the sliders and watch the box — and, below it, the arithmetic of how wide it really ends up. Then flip box-sizing.

The fix every professional applies first

By default (content-box), width means the width of the content only. Add padding and border and the box grows past the width you asked for — so a 300px-wide card with 20px padding and a 2px border is really 344px, and your carefully planned layout overflows. It is the most confusing default in CSS, and nobody would design it that way today.

border-box fixes it: width means the width of the whole visible box, and padding and border fit inside. Almost every professional stylesheet on the web starts with these lines:

*, *::before, *::after {
  box-sizing: border-box;
}

Put it at the top of your styles.css today and never think about it again.

Shorthand: going clockwise

Padding and margin have four sides. You can set them one by one — padding-top, padding-right… — or in one line, always starting at the top and going clockwise: top, right, bottom, left. Remember it as TRouBLe.

Block, inline, inline-block

Boxes come in two main behaviors, and it explains a lot of "why won't this move?" moments.

• Block — <p>, <h1>, <div>, <section>. Starts on a new line and stretches the full width available. Respects width, height, padding and margin in every direction.
• Inline — <a>, <strong>, <span>. Sits inside a line of text, only as wide as its content. Ignores width and height, and ignores top and bottom margin. That's why a link won't get taller when you give it a height.
• Inline-block — sits in a line like inline, but respects width, height and all margins like block. Set with display: inline-block;. The classic choice for a link styled as a button.

The strange one: margin collapse

Put a paragraph with margin-bottom: 30px directly above one with margin-top: 20px. You'd expect a 50px gap. You get 30px. Vertical margins between blocks collapse — the larger one wins and the smaller disappears. Horizontal margins never do.

It's intentional — it stops stacked paragraphs doubling their spacing — but it catches everyone once. The modern habit that avoids it entirely: put spacing on one side only, usually the bottom, or let layout tools (Flexbox and Grid, next modules) handle gaps with their own gap property, which never collapses.

Which spacing?

See it in DevTools

Inspect any element and scroll to the bottom of the Styles pane (or open the Computed tab). You'll find a small diagram of nested rectangles — margin, border, padding, content — with the real pixel values for that element. Hover over an element in the Elements panel and the page highlights its layers in the same colors: orange margin, green padding, blue content. It's the fastest way to answer "where is this gap coming from?"

Three things beginners get wrong

1. Boxes wider than planned. Width plus padding plus border. Fix it forever with box-sizing: border-box.

2. Padding and margin swapped. Space inside the colored area is padding; space between things is margin.

3. Giving inline elements height or vertical margin. It's ignored. Make the element inline-block or block first.

Words you now own

box model

Content, padding, border, margin — every element's four layers.

padding

Space inside the border.

margin

Space outside the border.

box-sizing: border-box

Makes width include padding and border.

shorthand

Setting several sides in one line, clockwise from the top.

block / inline

Full-width boxes on new lines, versus boxes flowing in a line of text.

margin collapse

Adjacent vertical margins merging into the larger one.

*, *::before, *::after { box-sizing: border-box; }

main {
  max-width: 70ch;
  margin: 0 auto;
  padding: 0 1rem;          /* breathing room on phones */
}

button[type="submit"] {
  padding: 0.6rem 1.2rem;   /* top/bottom, left/right */
  border: 2px solid #0a5856;
  background: #0d6e6b;
  color: white;
  border-radius: 6px;
}

Plate 2.3 · Phase 2 — Finishes · 20 minutes

Color, units and modern color functions

Two kinds of number fill every stylesheet: colors and sizes. This module teaches you to read and write both fluently — and to choose the kinds that make a site hold together when someone zooms in, turns on dark mode, or opens it on a phone.

At the paint counter

Walk into a Sherwin-Williams and there are two ways to ask for a color. You can read out the code on a chip — exact, but meaningless to a human. Or you can describe it the way painters think: which color, how vivid, how light. CSS offers both.

Any of them can take a fourth value for transparency: rgb(13 110 107 / 50%), hsl(178 79% 24% / 0.5). Transparency is called alpha.

Mix one yourself

Drag the sliders. Every format updates at once, and the strip along the bottom shows the same hue at nine lightness steps — exactly how a real design system builds a color scale.

Two modern color tools

color-mix() blends two colors, the way you'd add white to a tin of paint: color-mix(in oklch, #0d6e6b 20%, white) gives a pale tint of your brand color for a background — no designer needed. In Module 2.8 you'll replace that hex code with a named value, var(--brand), so the tint updates automatically whenever the brand color changes.

currentColor means "whatever the text color is here". Set an icon's fill or a border to currentColor and it always matches the surrounding text — including on hover and in dark mode.

Both are supported in every current browser. You'll lean on them heavily in Module 2.8, when a whole site gets themed from a handful of variables.

Units: absolute and relative

Sizes come in two families. Absolute units are fixed, like inches on a tape measure. Relative units are proportions, like a recipe: "two cups of flour per four servings" — scale the servings and every ingredient scales with it.

Which unit?

Three things beginners get wrong

1. Font sizes in px. They ignore the visitor's own default text-size setting. Use rem.

2. Twenty slightly different grays. #333, #343434, #3a3a3a… scattered across a stylesheet. Pick a small palette once and reuse it — Module 2.8 makes that automatic.

3. Pure black text on pure white. It's harsh on screens. A very dark gray, like #1a1f1e, reads more comfortably and still passes contrast easily.

Words you now own

hex

A color as six hexadecimal digits: #rrggbb.

HSL

Hue, saturation, lightness — color as a painter describes it.

OKLCH

A perceptually even color format, ideal for palettes.

alpha

Transparency, from 0 to 1 (or 0% to 100%).

color-mix()

Blends two colors in a chosen color space.

rem

Relative to the root font size — the default for text.

em

Relative to the element's own font size.

vw / vh / dvh

Percentages of the window's width and height.

ch

The width of a "0" — handy for text line length.

/* Brand: #0d6e6b  ≈  oklch(48% 0.08 190) */
body {
  color: #1b2321;             /* very dark gray */
  /* off-white — 15.2 : 1 against the text */
  background: #fbf8f3;
  font-size: 1rem;
}
p { max-width: 65ch; }
a { color: #0d6e6b; }
button[type="submit"] { background: #0d6e6b; }
.intro {
  background: color-mix(in oklch, #0d6e6b 12%, white);
  padding: 1rem;
}
h1 { font-size: 2.5rem; }     /* was 40px */

Plate 2.4 · Phase 2 — Finishes · 25 minutes

Typography on the web

The web is mostly words, so how words are set is most of how a site feels. Good typography is invisible — people just find the page easy and trustworthy. Bad typography is felt instantly, even by people who couldn't tell you why.

Designed to be read at 70 miles an hour

Every sign on an American interstate uses a typeface engineered for one job: to be read in a split second, from a moving car, at night, in the rain. Its letters are open, its spacing generous, its sizes set by exact rules for distance. Nobody driving past thinks "what a lovely font". They just read the exit number and take the ramp.

Families, and why you need fallbacks

You never name just one font. You write a font stack — a list the browser tries in order, ending in a generic family that always exists:

body {
  font-family: "Source Serif 4", Georgia,
    "Times New Roman", serif;
}

If the first font hasn't loaded yet, or fails, the next takes over. The zero-download option many professional apps use is the system stack — the font your visitor's own device already uses, which is San Francisco on an iPhone and Segoe UI on Windows: font-family: system-ui, sans-serif;

Loading a web font

For a distinctive typeface, Google Fonts is free and the easiest start: pick a family, choose only the weights you'll actually use, and paste the <link> it gives you into your <head>. Three rules keep it fast:

• Two families at most. One for headings, one for text — or one for both. A third almost always looks like an accident.
• Only the weights you use. Each weight is usually a separate file to download — unless the family is a variable font, which packs every weight into one file (Google Fonts labels these). Regular, italic and bold usually cover body text.
• display=swap (Google adds it for you) shows the fallback font immediately and swaps in the web font when it arrives — so text is never invisible while loading.

Larger projects often self-host the font files — .woff2, the compressed web format — using an @font-face rule. Same result, one less company involved in every page load.

The properties that matter

Tune it by eye

Drag the sliders and read the paragraph as you do. The badges underneath measure what professionals check: size, line spacing, and characters per line.

It starts deliberately bad: small, cramped, and lines far too long. Get all three badges green and notice how much calmer the same words feel. (On a phone, the screen itself is narrower than a comfortable line, so it caps the length for you — the third badge will say so. That's normal: phone lines are shorter.)

A type scale: sizes that belong together

Headings shouldn't be sized one by one by feel. Professionals pick a base size and a ratio, and multiply: each step up is the previous size times the ratio. The sizes then relate to each other the way notes in a musical scale do — which is literally where the ratio names come from.

:root {
  --step-4: 2.441rem;   /* h1 */
  --step-3: 1.953rem;   /* h2 */
  --step-2: 1.563rem;   /* h3 */
  --step-1: 1.250rem;   /* h4 */
  --step-0: 1.000rem;   /* body */
  --step-minus-1: 0.800rem;   /* small */
}

Small ratios suit dense interfaces and dashboards; large ratios suit editorial pages and landing pages with big dramatic headlines. Copy the generated CSS into your stylesheet — you'll learn exactly what --step-1 means in Module 2.8.

Hierarchy is more than size

Size is only one of four tools for showing what's important. The others are weight (bold versus regular), color (dark versus muted gray), and space (more room above a heading than below it, so it clearly belongs to the text that follows). Most good designs use two or three of these at once and keep the sizes restrained.

Quick check

Three things beginners get wrong

1. Too many fonts. Three typefaces and five weights reads as chaos. Two families, three or four weights, total.

2. Body text too small and too wide. 14px text stretched across a 1400px screen is the classic amateur page. 16px or more, and 60–75 characters a line.

3. Centered or justified paragraphs. Center a short headline if you like. Long text is always left-aligned.

Words you now own

typeface / font

A design of letters, and one specific weight or style of it. Used loosely as synonyms.

serif / sans-serif

Letters with small feet, and letters without.

font stack

A list of fonts to try in order, ending in a generic family.

system-ui

The visitor's own device font. Zero download.

font-display: swap

Show fallback text immediately; swap in the web font when ready.

woff2

The compressed file format for web fonts.

line-height

Space between lines. Best unitless, 1.5–1.7 for body text.

measure

Line length. Aim for 60–75 characters.

type scale

A set of sizes built from one base and one ratio.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect"
      href="https://fonts.gstatic.com"
      crossorigin>
<link rel="stylesheet"
      href="https://fonts.googleapis.com/css2?
family=Source+Serif+4:ital,wght@0,400;0,700;1,400
&family=Archivo:wght@600&display=swap">

body {
  font-family: "Source Serif 4", Georgia,
    "Times New Roman", serif;
  font-size: 1.0625rem;      /* 17px */
  line-height: 1.6;
}
p, li { max-width: 65ch; }

h1,
h2,
h3 {
  font-family: Archivo, "Helvetica Neue", Arial, sans-serif;
  line-height: 1.2;
}
h1 { font-size: 2.441rem; }   /* 1.25 scale, three steps up */
h2 { font-size: 1.953rem; }
h3 { font-size: 1.563rem; }

.label {
  text-transform: uppercase;
  letter-spacing: 0.08em;
  font-size: 0.8rem;
}

Plate 2.5 · Phase 2 — Finishes · 30 minutes

Flexbox: arranging things in a line

Until now, every box on your page has stacked straight down, one under another. Flexbox is how you put things side by side — a logo on the left and links on the right, three cards in a row, a button perfectly centered. It's the layout tool you'll reach for every single day.

Books on a shelf

Picture one shelf in the stacks at the New York Public Library. The shelf is the container; the books are the items on it.

.shelf {
  display: flex;
  justify-content: space-between;
  align-items: center;
  gap: 1rem;
}

The flexbox playground

Change the settings and watch the four items rearrange. The CSS underneath is exactly what you'd write. Then try the four challenges — they tick themselves off when your settings produce the layout described.

.container {
  display: flex;
  flex-direction: row;
  justify-content: flex-start;
  align-items: stretch;
  flex-wrap: nowrap;
  gap: 1rem;
}

justify versus align: the one that confuses everybody

justify-content works along the main axis. align-items works across it. In a row, justify is horizontal and align is vertical. Switch to flex-direction: column and they swap — justify becomes vertical. Try it in the playground: set justify to center, then flip the direction, and watch what moves.

Growing and shrinking

Items have a size they'd like to be, and Flexbox decides what to do with spare room or a squeeze. The shorthand you'll use nearly every time:

• flex: 1 — "take a share of any spare space." Give it to one item and it fills the gap; give it to three and they split the space equally. It's how you make three equal-width cards.
• flex: none — "stay exactly your natural size." Good for icons and logos that must never squash.
• margin-left: auto on one item — pushes it, and everything after it, as far right as possible. The classic trick for a navbar with the logo on the left and a "Sign in" button on the far right.

Four patterns you'll build again and again

/* 1. Navbar: logo left, links right */
.site-header {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

/* 2. Dead-center anything */
.hero {
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 60vh;
}

/* 3. A row of equal cards that wraps on small screens */
.cards { display: flex; flex-wrap: wrap; gap: 1.5rem; }
/* grow, shrink, but start at 16rem wide */
.card  { flex: 1 1 16rem; }

/* 4. Footer stays at the bottom on short pages */
body {
  display: flex;
  flex-direction: column;
  min-height: 100dvh;
}
main { flex: 1; }

Number 2 ended a twenty-year joke: "how do you center a div?" was the web's most famous unanswerable question. Now it's three lines.

See it in DevTools

In the Elements panel, any element with display: flex gets a small flex badge beside it. Click it and the page overlays the container's lines, gaps and free space. In the Styles pane, a small icon next to display: flex opens a visual editor for justify and align — click through the options and watch your real page change.

Quick check

Three things beginners get wrong

1. display: flex on the children. It goes on the parent. The children become flex items automatically.

2. justify and align the wrong way round. Ask "which way is the main axis?" first. Row: justify is horizontal. Column: justify is vertical.

3. Margins for spacing between items. Use gap. It only ever goes between items, never doubles, and never collapses.

Words you now own

flex container

The parent with display: flex.

flex item

Each direct child of a flex container.

main axis

The direction items are laid out — row or column.

cross axis

The direction at right angles to the main axis.

justify-content

Spacing along the main axis.

align-items

Alignment across the cross axis.

gap

Space between items only.

flex: 1

Take an equal share of any spare space.

<header class="site-header">
  <a class="site-name" href="index.html">Harbor Coffee</a>
  <nav aria-label="Main">
    <ul>
      <li><a href="menu.html">Menu</a></li>
      <li><a href="about.html">About</a></li>
      <li><a href="contact.html">Contact</a></li>
    </ul>
  </nav>
</header>

.site-header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  /* lets the nav drop below on very narrow screens */
  flex-wrap: wrap;
  gap: 1rem;
  padding: 1rem;
}
.site-header ul {
  display: flex;
  gap: 1.25rem;
  list-style: none;
  margin: 0;
  padding: 0;
}

/* sticky footer */
body {
  display: flex;
  flex-direction: column;
  min-height: 100dvh;
  margin: 0;
}
main { flex: 1; }

Plate 2.6 · Phase 2 — Finishes · 30 minutes

CSS Grid: the floor plan

Flexbox lines things up in one direction. Grid lays out a whole page in two — rows and columns at once, like an architect's floor plan. It's the tool that finally made web layout feel like design rather than a fight.

The Manhattan street grid

In 1811, New York's planners laid a grid over Manhattan: avenues running north–south, streets running east–west. Every building since has been placed by those coordinates — "5th Avenue at 34th Street". And a big building doesn't have to fit in one block: Central Park spans from 59th to 110th Street and across three avenues. CSS Grid works exactly the same way.

The basics

.page {
  display: grid;
  /* a fixed sidebar, and the rest */
  grid-template-columns: 250px 1fr;
  gap: 1.5rem;
}

That new unit, fr, means a fraction of the leftover space. 1fr 2fr splits the room one-third to two-thirds; 250px 1fr gives the sidebar exactly 250px and everything remaining to the main column. And repeat(3, 1fr) is shorthand for three equal columns.

Like Flexbox, display: grid goes on the parent, gap spaces the tracks, and the direct children become grid items. Unlike Flexbox, you define the structure first and the content fills it.

Draw the page as a map

The most readable feature in all of CSS: you literally draw your layout as text. Each quoted line is a row; each word names the area in that cell. Repeat a word to make an area span several cells. Edit the map below, or load a preset.

.page {
  display: grid;
  grid-template-areas:
    "header header"
    "aside  main"
    "footer footer";
  grid-template-columns: 220px 1fr;
  grid-template-rows: auto 1fr auto;
}
header { grid-area: header; }

Each area is then assigned in one line per element: header { grid-area: header; }. Rearranging the whole page for a phone later — sidebar under the content instead of beside it — means redrawing the map, not touching the HTML. You'll do exactly that in Module 2.7.

The responsive gallery with no media queries

One line of Grid produces a gallery that fits as many columns as there's room for, and reflows as the screen narrows:

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  gap: 1rem;
}

Read it aloud: "repeat as many columns as fit; each at least 200px, and sharing any leftover space equally." Drag the container width and watch.

One refinement professionals add: minmax(min(200px, 100%), 1fr). If the container is ever narrower than 200px — a narrow sidebar, a small old phone — a plain 200px minimum would stick out the side. min(200px, 100%) means "200px, or the full width if that's smaller".

.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
  gap: 10px;
}

Placing by line numbers

When you don't want named areas, place items by the lines they start and end on:

/* from line 1 to line 3: two columns wide */
.feature { grid-column: 1 / 3; }
/* -1 means the last line: full width */
.banner  { grid-column: 1 / -1; }
/* two rows tall, wherever it lands */
.tall    { grid-row: span 2; }

That 1 / -1 is worth memorizing — "stretch across everything" — and you'll use it constantly for full-width banners inside a grid.

See it in DevTools

Like Flexbox, grid containers get a grid badge in the Elements panel. Turn it on and the page overlays the grid lines, their numbers, and any area names. It's the fastest way to see why something landed in the wrong cell.

Quick check

Three things beginners get wrong

1. Percentages instead of fr. 50% 50% plus a gap overflows its container. 1fr 1fr accounts for the gap automatically.

2. Non-rectangular areas. Each named area must form a rectangle. An L-shape is invalid, and the whole template silently stops working. The editor above tells you when that happens.

3. Using Grid for a single row of buttons. One direction is Flexbox's job. Grid shines when rows and columns need to line up.

Words you now own

grid container

The parent with display: grid.

track

A single column or row.

grid line

The numbered boundaries between tracks, starting at 1.

fr

A fraction of the leftover space.

repeat()

Shorthand for many identical tracks.

grid-template-areas

A text map of named regions.

minmax()

A track size with a floor and a ceiling.

auto-fit

As many tracks as will fit.

span

Stretch across a number of tracks.

body {
  display: grid;
  grid-template-areas:
    "header"
    "main"
    "footer";
  /* footer stays at the bottom */
  grid-template-rows: auto 1fr auto;
  min-height: 100dvh;
  margin: 0;
}
.site-header { grid-area: header; }
main         { grid-area: main; }
footer       { grid-area: footer; }

.gallery {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(min(200px, 100%), 1fr));
  gap: 1rem;
}
.gallery img { width: 100%; height: auto; display: block; }

Plate 2.7 · Phase 2 — Finishes · 30 minutes

Responsive design: one page, every screen

Your site will be opened on a phone on the subway, a tablet on the couch, a laptop at work and a 27-inch monitor at home — often by the same person on the same day. You won't build four sites. You'll build one that adapts. That's responsive design, and it is simply how websites are made now.

Lemonade takes the shape of the glass

Pour a pitcher of lemonade into a tall glass, a mason jar, or a thermos. It's the same lemonade every time — it just takes the shape of whatever holds it. A responsive page is the same content, the same HTML, flowing into whatever screen holds it. You don't write a different page for a phone; you write rules for how the one page should settle into each shape.

This matters more than any other module in Phase 2 for one reason: over half of all web traffic worldwide comes from phones, and for local businesses — restaurants, salons, contractors — it's often far more. For many of your visitors, the phone version is the site.

Three ingredients, in order of importance

1. The viewport meta tag — the line from Module 1.1: <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, phones pretend to be a 980px desktop and shrink everything to an unreadable thumbnail. Nothing else in this module works without it.
2. Fluid layouts — sizes that stretch and wrap by themselves: fr, percentages, max-width, flex-wrap, auto-fit with minmax(). You already have most of these from the last three modules, and they do about 80% of the work with no special rules at all.
3. Media queries — for the remaining 20%, rules that only apply when the screen is at least (or at most) a certain width.

And one line every stylesheet needs, so images never burst out of their container on a narrow screen:

img, video {
  max-width: 100%;
  height: auto;
}

Media queries

/* Base styles: apply everywhere, starting with phones */
.layout { display: grid; gap: 1rem; }

/* From 48rem (768px) upward: two columns */
@media (min-width: 48rem) {
  .layout { grid-template-columns: 2fr 1fr; }
}

Read it as a sentence: "when the screen is at least 48rem wide, apply these rules as well." The width at which a layout changes is called a breakpoint.

You'll also see a newer, more readable way to write the same query: @media (width >= 48rem). It works in all current browsers and means exactly the same thing.

Mobile-first: start small, add as you grow

.nav { flex-direction: column; }

@media (min-width: 48rem) {
  .nav { flex-direction: row; }
}

.nav { flex-direction: row; }

@media (max-width: 47.99rem) {
  .nav { flex-direction: column; }
}

Resize a real page

Below is a small café page with real media queries at 40rem and 64rem. Drag the width, or jump to a device, and watch the layout reorganize: one column on a phone, two on a tablet, three plus a horizontal nav on a laptop. The badges show which rules are active.

.cards { display: grid; gap: 12px; }
@media (min-width: 40rem) {
  .cards { grid-template-columns: 1fr 1fr; }
}
@media (min-width: 64rem) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

Choosing breakpoints

Set breakpoints where your content breaks, not where devices are. New phones and tablets launch every year in new sizes; chasing them is hopeless. Instead, narrow your browser slowly until the layout starts to look wrong — a line too long, a card too squashed — and put a breakpoint there. Most sites need only two or three. Common starting points: about 40rem (640px) and 64rem (1024px).

Use rem for breakpoints rather than px, for the reason in Module 2.3: when a visitor enlarges their text, the layout adapts to that too.

Media queries ask about the screen. In Module 2.10 you'll meet container queries, which ask about the space one component sits in — the next step once your pages are responsive.

Queries that aren't about width

Fingers are not mouse pointers

A mouse pointer is one pixel precise. A thumb is roughly the size of a quarter. On touch screens, aim for every tappable thing to be at least 44 × 44px — Apple's guideline (Google's Android guideline is 48) — with space between neighbors, so nobody in a moving Chicago L train taps "Delete" when they meant "Edit". Padding (Module 2.2) is how you get there without making things look bigger. The accessibility minimum you met in Module 1.8, WCAG 2.2's 24 × 24px, is the floor; 44 is the target.

Quick check

Three things beginners get wrong

1. Fixed pixel widths. width: 1100px guarantees a sideways-scrolling page on every phone. Use max-width instead — "no wider than", which shrinks happily.

2. Hiding content on mobile. Phone visitors want the same information. Rearrange it; don't delete it.

3. One breakpoint per device. Breakpoints follow content. Two or three good ones beat twelve.

Words you now own

responsive design

One page that adapts to any screen size.

viewport

The visible area of the page in the browser.

fluid layout

Layout built from flexible sizes that stretch and wrap.

media query

A block of CSS applied only when a condition is true.

breakpoint

A width where the layout changes.

mobile-first

Phone styles as the base; min-width queries add to them.

touch target

A tappable area. Aim for 44 × 44px; 24 × 24px is the WCAG minimum.

img, video { max-width: 100%; height: auto; }

/* Phones first: one column, nav stacked */
body {
  display: grid;
  grid-template-areas: "header" "main" "aside" "footer";
  grid-template-rows: auto 1fr auto auto;
  min-height: 100dvh;
  margin: 0;
}
.site-header ul {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
}
/* bigger tap area */
.site-header a {
  display: inline-block;
  padding: 0.75rem 0.5rem;
}

.table-wrap { overflow-x: auto; }

/* From 48rem (768px) up: sidebar beside the content,
   nav in a row */
@media (min-width: 48rem) {
  body {
    grid-template-areas:
      "header header"
      "main   aside"
      "footer footer";
    grid-template-columns: 1fr 16rem;
    grid-template-rows: auto 1fr auto;
  }
  .site-header ul { flex-direction: row; gap: 1.25rem; }
}

Plate 2.8 · Phase 2 — Finishes · 25 minutes

Custom properties and dark mode

By now your stylesheet has the same brand color typed in a dozen places. Change your mind about it and you're hunting through every file. This module gives CSS a memory — named values you define once and use everywhere — and with it, dark mode almost for free.

Cell B2 in a spreadsheet

In Excel, you don't type the sales-tax rate into two hundred formulas. You put 8.25% in one cell, name it, and every formula refers to it. When Texas changes the rate, you edit one cell and the whole workbook recalculates. Custom properties — usually called CSS variables — are exactly that for your stylesheet.

:root {
  --brand: #0d6e6b;          /* define once… */
  --radius: 10px;
  --space: 1rem;
}

.button {
  background: var(--brand); /* …use everywhere */
  border-radius: var(--radius);
  padding: var(--space);
}

• The name must start with two hyphens: --brand, --space-lg.
• :root means the <html> element — the top of the page — so everything inside can see the value.
• var(--brand) reads it. var(--brand, teal) supplies a fallback if it isn't defined.

Design tokens: the brand book in code

Large companies keep a brand guidelines book: the exact red, the exact typeface, the exact corner radius, used at every location. On the web, those decisions become a short block of variables called design tokens. A typical set is surprisingly small:

:root {
  /* color */
  --bg: #fbf8f3;   --surface: #ffffff;  --text: #1b2321;
  --muted: #5b6663; --line: #e3ddd3;    --brand: #0d6e6b;
  /* shape and space */
  --radius: 10px;  --space: 1rem;
  /* type — the scale you generated in Module 2.4 */
  --step-0: 1rem;  --step-1: 1.25rem;  --step-2: 1.563rem;
}

Play with a themed component

Everything in the card below — colors, corners, spacing — reads from variables. Change a token and every part that uses it updates at once. Then switch to dark: only the color tokens change, and not a single component rule is touched.

:root {
  --bg: #fbf8f3;
  --surface: #ffffff;
  --text: #1b2321;
  --muted: #5b6663;
  --line: #e3ddd3;
  --brand: #0d6e6b;
  --radius: 10px;
  --space: 16px;
}

/* the component never changes: */
.card {
  background: var(--surface);
  border-radius: var(--radius);
  padding: var(--space);
}

Variables cascade, too

Custom properties follow the same inheritance rules as color (Module 2.1). That means you can override one inside a section, and only that section changes:

.card {
  background: var(--surface);
  border-color: var(--brand);
}

/* this one card is orange */
.card.featured { --brand: #c9731b; }
/* lighter text, only in the footer */
.footer        { --text: #c5cfcc; color: var(--text); }

Same rule, same component, different values by context. That's how design systems keep hundreds of components consistent without hundreds of variations.

Notice the footer also needs color: var(--text) of its own. If only body reads the variable, body's color was already worked out from the :root value, and the footer simply inherits that finished color. Changing a variable affects only the rules that read it, at or below the element where you changed it.

Dark mode in one block

Because every color in your site now comes from a token, dark mode is just a second set of values:

:root { color-scheme: light dark; }

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #111615;  --surface: #1a2120;  --text: #e7eeec;
    --muted: #9aaca8; --line: #2a3533;  --brand: #5ad3c6;
  }
}

prefers-color-scheme is the media query from Module 2.7: it's true when the visitor's phone or computer is set to dark mode. color-scheme: light dark tells the browser to match its own parts too — scrollbars, form fields, checkboxes — so they don't glare white in a dark page.

Designing dark, not inverting

• Not pure black. #000 behind white text causes a shimmering effect for many readers, especially those with astigmatism. Use a very dark gray with a hint of your brand's hue.
• Lighten and soften the brand color. A deep teal that looks rich on white turns muddy on near-black. Dark themes need a lighter, slightly less saturated version.
• Show depth with lighter surfaces, not shadows. Shadows vanish on dark backgrounds; raised cards get a slightly lighter surface instead.
• Don't invert photos. Images stay as they are.
• Re-check every contrast pair with Module 1.8's checker. A theme is two themes to test.

Quick check

Three things beginners get wrong

1. Tokens named by color. --white that's dark gray in dark mode is a lie waiting to confuse someone. Name tokens by role.

2. Hard-coded colors left behind. One color: #333 hiding in a rule becomes an unreadable dark-on-dark patch in dark mode. Every color should come from a token.

3. Forgetting the second theme exists. Test every page in both modes before calling it done.

Words you now own

custom property

A named value, --name: value. Called a CSS variable.

var()

Reads a custom property, with an optional fallback.

:root

The top of the document, where global tokens live.

design token

A named design decision: a color, a space, a radius.

prefers-color-scheme

The media query for the visitor's light or dark setting.

color-scheme

Tells the browser to theme its own built-in parts to match.

data-theme

An attribute a toggle sets to override the system setting.

:root {
  color-scheme: light dark;
  --bg: #fbf8f3;  --surface: #ffffff;  --text: #1b2321;
  --muted: #5b6663;  --line: #e3ddd3;  --brand: #0d6e6b;
  --radius: 10px;  --space: 1rem;
  --step-0: 1rem;  --step-1: 1.25rem;
  --step-2: 1.563rem;  --step-3: 1.953rem;
}
@media (prefers-color-scheme: dark) {
  :root {
    --bg: #111615;  --surface: #1a2120;  --text: #e7eeec;
    --muted: #9aaca8;  --line: #2a3533;  --brand: #5ad3c6;
  }
}

body {
  background: var(--bg);
  color: var(--text);
  font-size: var(--step-0);
}
h1     { font-size: var(--step-3); }
a      { color: var(--brand); }
.card {
  background: var(--surface);
  border: 1px solid var(--line);
  border-radius: var(--radius);
  padding: var(--space);
}
button[type="submit"] {
  background: var(--brand);
  color: var(--bg);
  border-radius: var(--radius);
}

Plate 2.9 · Phase 2 — Finishes · 25 minutes

Transitions, transforms and tasteful motion

Motion is the most abused tool in web design and one of the most useful. Done well, it's barely noticed: a button that responds to your finger, a panel that slides in from where it came from. Done badly, it's the reason people close tabs. This module teaches both the mechanics and the restraint.

A good elevator

Step into a modern Otis elevator in a Chicago office tower. It doesn't lurch to full speed and slam to a stop — it eases out of the floor, cruises, and eases in to the next one. You barely notice the trip. An elevator that moved at one constant speed, starting and stopping instantly, would throw you off your feet.

Real objects accelerate and decelerate, and our brains expect it. That's the whole idea behind easing — and the reason motion that ignores it feels cheap and mechanical.

Transitions: smoothing a change

Normally when a style changes — on hover, say — it snaps instantly. A transition tells the browser to animate from the old value to the new one:

/* one more token: a darker brand shade */
:root { --jagon-brand-hover: #0a5856; }

.button {
  background: var(--brand);
  transition: background-color 200ms ease-out,
    transform 200ms ease-out;
}
.button:hover {
  background: var(--jagon-brand-hover);
  transform: translateY(-2px);
}
.button:active { transform: translateY(0) scale(0.97); }

Four parts: which property, how long, which easing curve, and optionally a delay. Hover over each button to feel the difference:

The middle one is what professionals ship: quick, subtle, and it presses in when you click, which feels like a physical button. The third is what beginners ship: slow, showy, and exhausting by the tenth time.

Easing: the elevator curves

Press Race. Every ball travels the same distance in exactly the same time — only the easing differs.

• ease-out — fast start, gentle stop. The default for things entering or responding — hovers, menus opening, toasts appearing. It feels responsive because movement begins immediately.
• ease-in — slow start, fast finish. For things leaving the screen.
• ease-in-out — the elevator. For things moving from one place to another on screen.
• linear — constant speed. Mechanical. Only for things that genuinely spin, like a loading indicator.
• cubic-bezier() — your own curve. The last lane overshoots and settles back, like a drawer that bounces slightly as it closes.

Transforms: move without disturbing anything

transform moves, turns and resizes an element visually — without pushing anything else on the page around. The dashed outline shows where the element really sits in the layout; the solid card is where it's drawn.

.card {
  transform: translate(60px, -30px)
             rotate(-15deg)
             scale(0.75);
}

Keyframe animations

Transitions go from A to B when something changes. For motion with several steps, or that plays on its own, use @keyframes:

@keyframes fade-up {
  from { opacity: 0; transform: translateY(12px); }
  to   { opacity: 1; transform: translateY(0); }
}

.toast {
  animation: fade-up 250ms ease-out;
}

The animation shorthand also accepts a delay, a repeat count (infinite for spinners) and a direction. Keep keyframe animations for genuine moments — a message arriving, a loader — not for everything that scrolls into view.

Motion with a purpose

• Feedback — "I received your tap": a button pressing in, a checkbox ticking.
• Orientation — "this came from there": a menu sliding from the icon that opened it.
• Attention — "look here": a new notification arriving. Sparingly.

Timing guide: small UI feedback 100–200ms; panels and menus 200–300ms; anything over 500ms needs a very good reason. Faster almost always feels better.

The non-negotiable: reduced motion

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Quick check

Three things beginners get wrong

1. transition: all. It animates properties you never meant to, and costs performance. Name the properties.

2. Too slow. 1 second feels elegant the first time and sluggish the hundredth. Most interface motion is under 300ms.

3. Ignoring reduced motion. A few lines of CSS separate "delightful" from "made someone feel sick".

Words you now own

transition

Animates a property from its old value to its new one.

easing

The acceleration curve of a motion.

ease-out / ease-in

Fast-then-slow for arriving; slow-then-fast for leaving.

cubic-bezier()

A custom easing curve.

transform

Visually move, rotate or scale without affecting layout.

@keyframes

A named, multi-step animation.

prefers-reduced-motion

The visitor's request for minimal animation.

:root { --jagon-brand-hover: #0a5856; }

.button, .site-header a {
  transition: background-color 180ms ease-out,
    color 180ms ease-out,
    transform 180ms ease-out;
}
.button:hover,
.button:focus-visible {
  background: var(--jagon-brand-hover);
  transform: translateY(-2px);
}
.button:active { transform: translateY(0) scale(0.97); }
.site-header a:hover,
.site-header a:focus-visible {
  color: var(--brand);
}

@keyframes fade-up {
  from { opacity: 0; transform: translateY(12px); }
  to   { opacity: 1; transform: translateY(0); }
}
h1 { animation: fade-up 300ms ease-out; }

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Plate 2.10 · Phase 2 — Finishes · 30 minutes · Final module of Phase 2

Modern CSS worth knowing in 2026

CSS changed more between 2022 and 2025 than in the previous decade. Things that used to need JavaScript, preprocessors or ugly workarounds are now a line of plain CSS in every current browser. This module covers the handful that change how you work day to day — and how to tell which new features are safe to use.

Why so much changed

For years, browsers shipped features at their own pace, and developers waited half a decade before a new feature was safe to use. Since 2022, Apple, Google, Microsoft and Mozilla have coordinated through a yearly project called Interop, agreeing which features to finish together. The result: features now arrive in Chrome, Safari, Firefox and Edge within months of each other. The four below work in all current browsers and are in daily professional use.

1. Container queries: components that know their own size

Media queries (Module 2.7) ask "how wide is the screen?". But the same card might sit in a wide main column and a narrow sidebar on the same page. What it really needs to know is "how wide is the space I'm in?". Think of a Crate & Barrel sofa sectional: the same pieces arrange differently in a studio apartment than in a family room — the room decides, not the city.

/* this box can be measured */
.card-slot { container-type: inline-size; }

/* stacked by default */
.card { display: grid; gap: 1rem; }

@container (min-width: 380px) {
  /* side by side when there's room */
  .card { grid-template-columns: 140px 1fr; }
}

One rule to remember: a container can't restyle itself based on its own size. The query measures .card-slot and styles what's inside it — here, the card.

Drag the slider: the screen isn't changing, only the container. The card rearranges itself at 380px and again at 560px.

.card-slot { container-type: inline-size; }
.card { display: grid; gap: 1rem; }
@container (min-width: 380px) {
  .card { grid-template-columns: 140px 1fr; }
}

This is the biggest shift in how components are built since Flexbox. A card designed this way works anywhere you put it — the essence of the component thinking you'll meet in Phase 6.

2. :has() — the parent selector

For twenty years, CSS could only look down: style a child based on its parent. :has() lets it look inside: style an element based on what it contains. Developers asked for it for two decades.

/* highlight a chosen option */
label:has(input:checked) { background: var(--brand-tint); }
/* cards with a photo */
.card:has(img)            { padding-top: 0; }
/* a form with an error inside */
form:has(:user-invalid)   { border-color: var(--danger); }

/* --brand-tint and --danger are two more tokens for your
   :root set:
   a pale brand color and an error red */

:user-invalid matches a field that breaks its rules — a required field left empty, an email without an @ — but only once the visitor has interacted with it, so the form doesn't show errors before anyone has typed.

label:has(input:checked) { background: var(--brand-tint); }
.box:has(input:checked)  { color: var(--brand); }

3. Native nesting

Rules can now live inside other rules, the way your HTML nests. The & means "the selector I'm inside".

.card { padding: 1rem; }
.card h3 { margin: 0; }
.card:hover { transform: translateY(-2px); }
.card.featured { border-color: var(--brand); }

.card {
  padding: 1rem;
  h3 { margin: 0; }
  &:hover { transform: translateY(-2px); }
  &.featured { border-color: var(--brand); }
}

One caution: nest two or three levels at most. Deep nesting produces long, highly specific selectors — the specificity arms race from Module 2.1.

4. clamp() — fluid sizes without breakpoints

clamp(minimum, preferred, maximum) picks the preferred value but never goes below the minimum or above the maximum. Combined with vw, it makes headlines that grow smoothly with the screen:

h1 { font-size: clamp(1.75rem, 1rem + 4vw, 3.5rem); }

Read it as: "about 4% of the screen width plus a base — but never smaller than 1.75rem on a phone or larger than 3.5rem on a big monitor." The 1rem + part matters: it keeps the size connected to the visitor's text setting (Module 2.3), so zooming still works.

Quick wins worth knowing

One nuance with @layer: styles that aren't in any layer beat every layered style, and !important reverses the layer order. Adopt layers for a whole stylesheet at once, not a rule here and there.

How to tell if something new is safe to use

New CSS features appear every few months. Before using one in a real project, check two places:

• MDN's Baseline badge. Every feature page on developer.mozilla.org now shows whether it's Baseline Widely available (safe everywhere for 2½+ years), Newly available (works in all current browsers, but people on older devices may miss out), or Limited availability (not yet in every browser).
• caniuse.com — type a feature name and see exactly which browser versions support it, with usage percentages.

Features still rolling out across browsers in 2025–26 — so check their Baseline status on MDN before relying on them: view transitions (animated changes between pages and states), anchor positioning (tooltips and menus that attach to a button without JavaScript), and scroll-driven animations.

Quick check

Three things beginners get wrong

1. Copying old tutorials. A 2017 article will teach floats and padding hacks for problems that are now one line. Check the date, and check MDN.

2. Using a brand-new feature without a fallback. Check Baseline first; enhance progressively.

3. Nesting everything five levels deep. Readability and specificity both suffer. Keep it shallow.

Words you now own

container query

Styles based on the size of a component's container, not the screen.

:has()

Selects an element based on what it contains.

nesting

Writing rules inside other rules, with & for the parent.

clamp()

A value with a minimum, a preferred size and a maximum.

Baseline

MDN's label for how widely a feature is supported.

progressive enhancement

Works for everyone; better where the browser supports more.

@layer

Named groups of CSS with an explicit priority order.