Preface

Before you begin

Right now, there is a web page open somewhere in front of you. Maybe it's this one. And I'm going to tell you something that most beginners are never told: you can read it.

A web page looks like magic. Buttons move, pictures appear, a form remembers your name. Many people decide at that moment that this world belongs to someone else, someone who "gets" computers. This book exists to take that idea apart.

Here is the secret. Every instruction that makes a page work is plain text. Not a special code only engineers can see, but ordinary words and symbols that you can read, change, and break on purpose to see what happens. The pictures, the fonts and the videos are the only parts that aren't text. Everything telling the browser what to do is.

The book is laid out as a path. Nine phases take you from how the web works, with no code at all, to building, styling and shipping real apps. Each phase is split into short modules, one sitting each, and every module ends with a short check so you know it landed before you move on. Whenever something new appears, it comes with a picture from ordinary life first: a page's structure is the frame of a house, its styling is the paint and the lighting, and its behavior is the wiring behind the switches. Technical words are kept to the few you really need, and each one is explained in plain words the first time it shows up.

Small labels along the way tell you what you're looking at. Key idea marks the one thing to keep from a module. Take note flags something easy to miss. Try it now means stop reading and do it. On a screen, you click your answer and see right away whether you were right. In print or as an ebook, the same questions are there, with the answers waiting at the end of each module.

So this book doesn't ask you to memorize anything. You'll try things. You'll guess, check, and find out whether you were right. Being wrong is fine; it's how the lesson sticks.

You don't need any experience. By the end you'll have built your first web page, then your first app, and you'll be able to open almost any page, look underneath, and know what you're seeing.

Turn the page. Read it to believe it.

The whole path, laid out

You are going to build things people can use on the internet.

Not by memorizing jargon. By building one small working thing at a time, in the same order a professional would rebuild their knowledge if they lost it all tomorrow.

Here is the honest shape of it. Web development is three skills stacked on top of each other, and almost everybody who quits, quits because they tried to learn all three at once.

The house you already understand

The frame & the rooms: Walls, doors, where the kitchen is. Nobody argues about paint before the walls exist.
The finishes: Paint, tiles, lighting, furniture. Same house, completely different feeling.
The wiring & plumbing: Flip a switch, something happens. This is the part that reacts to people.
The utilities outside: Water, power, the records office. Things that live somewhere else and get delivered.

The web page you are learning to build

HTML — structure: Headings, paragraphs, images, buttons. What things are.
CSS — appearance: Color, spacing, layout, responsiveness. What things look like.
JavaScript — behavior: Click, type, submit, update without reloading. What things do.
The backend — data & accounts: Databases, logins, payments. Things that must outlive the visitor's browser.

Every phase below adds exactly one of those layers and refuses to touch the next one until you have shipped something with the current one. Each lesson is a single sitting — 15 to 30 minutes — and ends with a check so you never advance on a foggy understanding. Many are followed by hands-on practice, shown separately as + practice: do it the same day or the next, but do it — that's where the skill actually forms.

9Phases

81Modules

~36hLesson time

~34hPractice time

5Portfolio projects

100%Assessed

How to use this

Do one module per sitting, in order. Do not read ahead — reading feels like progress and isn't. After each module, take the check. If you score below 4 out of 6, redo the module the same day; you will not remember it tomorrow. Two modules a day gets you through the whole manual in about ten weeks.

The three chips below each module

Quiz means a short set of questions. Build means you must produce a working file — the only real proof. Explain means you say it back in your own words out loud, to a person or an empty room; if you stumble, you don't have it yet.

The signs in the margin

A few small icons mark what matters. Each one always comes with its word, and each means one thing only, everywhere in this manual.

CriticalBreaks things, loses data, costs money or puts people at risk. Rare — read every one.

Take noteAn important detail that's easy to miss.

Key ideaThe one thing to remember from the module. One per module.

Pro tipA shortcut or habit professionals use.

Try it nowA hands-on step to do right now — in the page or on your own machine.

Concept iconsbrowser · internet · server · database · security · code · device

Prefer plain text? Icons can be switched off; labels stay.

After Plate 8

What "pro" actually means here

At the end of this manual you will be able to take a vague idea from a real person — "I want customers to book a table and I want to see the bookings on my phone" — and deliver a working, fast, accessible, secure application on a real domain, with the code in version control, tests that catch your mistakes, and a deployment that updates itself when you push. That is the job.

You will not know everything. Nobody does; the field is too big and moves too fast. What you will have is the thing professionals actually run on: a solid mental model of how the pieces fit, so that anything new you meet is a variation on something you already understand.

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.

Warm-up · from Module 1.6A form submits happily, but one field's value never arrives. What's the most likely cause?

The field has no name attribute. Only named fields are sent — the name is the key the value travels under.

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.

Key idea · The table test

If a value needs both its row heading and its column heading to make sense, it belongs in a table.

Schedules, price comparisons, standings, nutrition facts, opening hours by location. If it doesn't, it isn't a table — however neatly it lines up.

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>

Element	Means
<table>	The whole grid.
<caption>	The table's title — what the data is. First thing inside the table.
<thead> / <tbody> / <tfoot>	The header rows, the data rows, and totals at the bottom.
<tr>	One row. Tables are built row by row, never column by column.
<th scope="col">	A heading for the column below it.
<th scope="row">	A heading for the row beside it.
<td>	One ordinary data cell.
colspan / rowspan	A cell stretching across several columns or rows. Use sparingly — they make tables harder to read aloud.

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.

What a screen reader says for each cell Mark headings as ordinary <td>

Screen reader

Click a number in the table.

Table: forecast highs, first week of October (°F).

City	Mon	Tue	Wed	Thu
Chicago	64	59	61	57
Denver	71	68	55	60
Boston	62	63	58	56
Seattle	58	57	60	59

Cell	With real `<th scope>`	Headings as plain `<td>`
Denver, Wednesday	"Denver, Wednesday, 55"	"55"
Seattle, Monday	"Seattle, Monday, 58"	"58"

Notice that real headings make the reader announce row, column, and value on its own. Without them the listener hears a bare number and must rebuild the context from memory, for every cell.

Table, or not a table?

Does it belong in a table?0 / 5

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.

Pro tip · Tables on phones

A wide table doesn't fit a 390-pixel phone screen. The honest fix is to let the table scroll sideways inside its own container rather than squashing it — every comparison table in this manual does exactly that. You'll write that one line of CSS in Phase 2.

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.

Apply it · Module 1.7

Add one honest table to your site.

On about.html, added a table of your learning plan: phases as rows, with columns for topic and target finish date. Gave it a <caption>, a <thead> and a <tbody>. Used <th scope="col"> for column headings and <th scope="row"> for the phase names. Wrote the dates with <time datetime="…">, from Module 1.2.

What you should see — one way to do it

<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>

What you should see: the caption centered above, bold header cells, plain data cells — no borders yet. Browsers draw tables with no lines by default; Phase 2 adds them.

0 / 4 One table, built properly. It will look plain until Phase 2 — that's expected.

Assessment · Module 1.7

Six questions. Four correct to move on.

0 / 6 Answer each question — you'll get the reasoning immediately, right or wrong.

Say it out loud before you leave

"If a value needs its row and its column to make sense, it's a table. Headings are th with a scope. Every table gets a caption. Tables are for data, never layout." Short module, permanent rule.