Web development module 1: how the web works, and HTML

Day 1 — How the web works

Goal: explain in your own words what happens between typing an address and the page appearing.

Theory (20 min)

The web rests on a dialogue between two programs. The browser (Firefox, Chrome, Safari…) is the program running on your machine that displays pages. The server is a computer kept always on, somewhere on the Internet, whose job is to answer requests for pages. When you type an address, the browser sends a request to the server, and the server sends back a response: the page content. This request/response pair is the heart of the web — you will meet it again until the last day of the path.

A web address, called a URL (Uniform Resource Locator), splits into parts. Take https://developer.mozilla.org/en-US/docs/Learn:

• https is the protocol: the agreed language of the dialogue. HTTP means HyperText Transfer Protocol; the S adds encryption — nobody can read the conversation on the way.
• developer.mozilla.org is the domain name: it designates the server. A worldwide service called DNS (Domain Name System) translates it into an IP address, the machine's real number on the network.
• /en-US/docs/Learn is the path: which page, on that server.

The server's response usually contains three kinds of files, the three languages of this path: HTML describes the content and its structure (headings, paragraphs, images); CSS describes the appearance (colors, fonts, layout); JavaScript describes the behavior (what happens on a click). The classic analogy: HTML is the body, CSS the clothes, JavaScript the gestures.

One last point: opening an HTML file saved on your disk (double-click) also works, with no server and no Internet — the browser reads the local file. That is how you will work for three modules. The server only becomes necessary when you publish, in module 4.

Practice (30 min)

1. Open your browser and go to https://developer.mozilla.org/en-US/docs/Learn. Spot the protocol, the domain and the path in the address bar.
2. Open the developer tools with the F12 key (or right-click the page → "Inspect"). A panel opens: it is the browser's built-in laboratory, you will come back to it every day.
3. Click the Network tab of these tools, then reload the page (F5). You see every request scroll by: the HTML, the CSS, the images. Click the first line, look at the "Headers" tab: the requested URL, the GET method, the status code 200 (which means "OK").
4. Success criterion: you can point at the page's main request in the Network tab and read its status code.
5. Try an address that does not exist (add random letters to the path) and reload: the status becomes 404, "not found". You have just seen the two most famous responses of the web.

Agent tips: ask an agent "explain what the Network tab shows when I load this page" and paste the list of requests. Trap: it cannot see your screen — paste the real lines, not a summary. Proof to demand: that it names the exact status code YOU read in the tab.

Recap (10 min)

Three lines: what the browser and the server are, the three parts of a URL, the role of HTML, CSS and JavaScript. Then, without notes: tell the journey of a request out loud, as if to a friend.

Day 2 — Install VSCodium and create your first page

Goal: install the editor, create a working folder, write a first HTML file in it and open it in the browser.

Theory (20 min)

A code editor is a program for writing plain text: no bold, no colors saved into the file, just characters. It is the opposite of a word processor like Word, which mixes text and formatting together. HTML, CSS and JavaScript are plain text: the browser reads them as-is. We use VSCodium, the fully open-source build of Visual Studio Code, free for Windows, macOS and Linux.

An HTML file is a text file whose name ends in .html. The extension is a convention systems use to pick the opening program: double-clicking an .html file opens the browser.

HTML marks up content with tags: words between angle brackets that come in pairs, an opening one and a closing one (the same with a slash). The content sits between them:

<h1>Hello world</h1>

<h1> says "the main heading starts here", </h1> says "it ends here". The whole opening tag + content + closing tag is called an element.

Practice (30 min)

1. Download VSCodium from vscodium.com and install it.
2. Create a folder devweb in your Documents: the whole path will live in it.
3. Open VSCodium, then File → Open Folder → choose devweb. Create a new file and save it as index.html. The name index.html is a convention: it is the file a server serves by default for a folder.
4. Type exactly (by hand, no copy-paste):

<h1>Hello world</h1>
<p>This is my first web page.</p>

5. Save (Ctrl+S or Cmd+S), then double-click index.html in your file explorer: the browser opens and shows your heading and your paragraph.
6. Success criterion: the browser shows "Hello world" big, your sentence below, and the address bar starts with file:// — proof the page comes from your disk, not a server.
7. Change the text in VSCodium, save, reload the browser (F5): the change appears. This write → save → reload loop, you will run it hundreds of times.

Agent tips: "create an index.html file that shows a heading and a paragraph" is an order an agent executes in a second. Trap: it may write it in a different folder than yours. Proof to demand: the full path of the created file, then open it yourself in the browser.

Recap (10 min)

Three lines: what a code editor is, what a tag is, why index.html has a special name. Then, without notes: delete the file and recreate it from memory, until it displays in the browser.

Day 3 — The skeleton of an HTML page

Goal: write the complete skeleton of an HTML page from memory and understand each line's role.

Theory (20 min)

Yesterday, two lone tags were enough — the browser is forgiving. But a real page has a fixed skeleton, the same for every page in the world:

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

Line by line:

• <!DOCTYPE html> is not a tag but a declaration: "this document is modern HTML". Without it, the browser falls into a historical compatibility mode with strange behaviors.
• <html lang="en"> is the root: the whole document lives inside it. lang="en" is an attribute: a piece of information attached to the opening tag, in the form name="value". Here it declares the page's language — screen readers use it to pick the right voice, search engines to rank.
• <head> holds information about the page, invisible in the window: <meta charset="utf-8"> declares the character encoding (utf-8 covers accents and every alphabet), <title> gives the tab title and the title in search results.
• <body> holds everything displayed in the window.

Notice the nesting: elements contain one another like nesting dolls — title inside head, head inside html. You always close in the reverse order of opening, and you indent (shift with spaces) each level to read it at a glance.

Practice (30 min)

1. In VSCodium, replace the content of index.html with the skeleton above, typed by hand, with your own title and your own <h1>.
2. Save, reload the browser. Success criterion: the tab title shows your text (no longer "index.html" or the file address), and the page shows your heading.
3. Write a sentence with accented characters in the <body> (borrow a French word like "café"), save, reload: accents display correctly thanks to charset="utf-8".
4. Change lang="en" to lang="fr", reload: nothing changes visually. That is normal: this attribute talks to machines (screen readers, search engines), not to eyes. Set en back.
5. Close VSCodium, reopen it, and rewrite the skeleton in a fresh file skeleton.html without looking at your notes. Compare, fix, repeat until the skeleton comes out right on the first try.

Agent tips: "check that my HTML skeleton is correct" with the whole file pasted is a reliable review. Trap: the model may "fix" a correct detail just to do something. Proof to demand: the list of real errors, each quoted, and zero gratuitous edits.

Recap (10 min)

Three lines: the role of head vs body, what an attribute is, why utf-8. Then recite the skeleton line by line, without looking.

Day 4 — Headings, paragraphs and comments

Goal: structure a long text with six heading levels, paragraphs, and leave invisible notes in the code.

Theory (20 min)

HTML offers six heading levels, from <h1> (most important) to <h6> (least). They express a hierarchy of meaning, not sizes: <h1> is the page's subject (one per page, by convention), <h2> its main parts, <h3> their sub-parts. Never skip a level: an <h3> does not directly follow an <h1>. This hierarchy is the table of contents that search engines and screen readers read.

Running text goes in <p> (paragraph). A surprising detail: the browser ignores line breaks and multiple spaces in your file — it crushes them into a single space. To split text into paragraphs, you need one <p> tag per paragraph.

Finally, the comment: text in the code that the browser ignores completely, for you or your readers:

<!-- this is a comment, invisible on the page -->

It starts with <!-- and ends with -->. Use it to explain a choice, to mark a section, or to temporarily hide a piece of page without deleting it.

Practice (30 min)

1. Create article.html with yesterday's skeleton. As <h1>: "My favorite animal" (or any topic you like).
2. Write a short article: two <h2> sections ("Its habitat", "Its diet"), one <h3> sub-section, and three <p> paragraphs spread inside them.
3. In the first paragraph, press Enter in the middle of a sentence. Success criterion: after reload, the line break does NOT appear — proof that the browser ignores line breaks in the file. Then split the sentence into two <p> and watch the break appear.
4. Add a comment <!-- to do: a photo --> before a section. Check it is invisible on the page, then right-click → "View page source": it is there. Source code is public by nature — never put a secret in it.
5. Validate the page: paste its code into validator.w3.org ("Validate by Direct Input" tab). Success criterion: "no errors".

Agent tips: "proofread this HTML and tell me if the heading hierarchy is correct" works well. Trap: the model may invent a rule ("you need an h2 before every p") that does not exist. Proof: make it quote the rule, then check it on MDN.

Recap (10 min)

Three lines: the h1→h6 hierarchy, why line breaks are not enough, what a comment is for. Then rewrite article.html without notes.

Day 5 — Lists and important text

Goal: write bulleted and numbered lists, and mark text importance with strong and em.

Theory (20 min)

Two kinds of lists: the unordered list <ul> shows bullets — order does not matter (groceries, qualities); the ordered list <ol> numbers — order matters (a recipe, a ranking). In both cases, each item goes in a <li> (list item):

<ul>
  <li>Apples</li>
  <li>Bread</li>
</ul>
<ol>
  <li>Preheat the oven</li>
  <li>Mix the batter</li>
</ol>

Lists nest: a <ul> can live inside a <li>, to make sub-lists (an outline, a menu).

For text, two tags of meaning, not appearance: <strong> marks important content (a warning, a keyword) — the browser shows it bold, but the primary meaning is importance; <em> (emphasis) marks an insistence, like stressing a word when speaking — shown in italic. You will also meet <b> and <i>, which mean nothing beyond "bold" and "italic": prefer strong and em, which survive screen readers.

Practice (30 min)

1. Open yesterday's article.html. In the "diet" section, replace the paragraph with a <ul> list of what your animal eats.
2. Add a "A day with it" section with an <ol> of three moments of its day, in order.
3. Inside one <li>, add a nested <ul> sub-list of two items. Reload: the sub-list appears indented.
4. Wrap the most important word of a paragraph in <strong>, and a word you would stress out loud in <em>. Success criterion: on the page, the first is bold, the second italic, and your source shows strong and em, not b or i.
5. Validate again with the W3C validator: zero errors.

Agent tips: "turn this paragraph into a bulleted list" is a perfect refactor for an agent. Trap: it may rephrase your text along the way. Proof: compare the text before/after — only the shape may move, not the words.

Recap (10 min)

Three lines: ul vs ol, the role of li, the difference in meaning between strong and b. Then recreate a nested list from memory.

Day 6 — Links

Goal: connect your pages to each other and to the outside, and create jumps inside a page.

Theory (20 min)

The link is the invention that gave the web its name: hypertext — text that points to other text. The tag is <a> (anchor), and its destination lives in the href attribute:

<a href="https://developer.mozilla.org/">The MDN docs</a>

The text between the tags is what you see and click; the href attribute is where it leads. Pick link text that names the destination ("the MDN documentation"), never "click here": a screen reader can list all the links of a page, and a list of "click here" says nothing.

Three kinds of destinations:

• External link: a full URL, with the https://. Without the protocol, the browser thinks it is a local file.
• Relative link: to a file next to yours: <a href="article.html">My article</a>. The path starts from where the page sits. This is how the pages of a site connect to each other.
• Anchor: to a spot within the page. Mark the target with an id attribute — <h2 id="recipe"> — and the link points to it with a hash: <a href="#recipe">See the recipe</a>. This is how tables of contents at the top of long pages work.

Practice (30 min)

1. In index.html, add a paragraph with an external link to your favorite site, with explicit link text.
2. Add a relative link to article.html. Click it: your article opens. Add in article.html a link back to index.html. Success criterion: you can navigate between your two pages by clicking links only, without touching the address bar.
3. In article.html, give each <h2> an id, then add a "Contents" list at the top whose each <a href="#..."> points to a section. Reload and test each link: the page must scroll to the section.
4. Deliberately write an external link without the https:// (href="developer.mozilla.org"), click: the browser looks for a local file and fails. Fix it. You have just seen the most common link failure among beginners.

Agent tips: "check the links in this file and list the broken or misspelled ones" — paste the file. Trap: it cannot test external links (it does not open them), it only reads. Proof to demand: the list with the exact line of each suspect link, then click-test them yourself.

Recap (10 min)

Three lines: the three kinds of links, the role of href, why "click here" is bad link text. Then redo the anchor table of contents without notes.

Day 7 — Images

Goal: insert an image with a correct alternative text, and caption it.

Theory (20 min)

The <img> tag has two required attributes: src (source: the path to the image file, relative like a link) and alt (alternative: the text that replaces the image). A peculiarity: <img> is an orphan tag — no closing tag, no content: <img src="photo.jpg" alt="A ginger cat asleep on a keyboard">.

The alt is the most important attribute of the day. It serves in three cases: the image does not load (slow connection, missing file), the visitor uses a screen reader, a search engine indexes the page. The writing rule: describe what the image brings, as if describing it on the phone. A purely decorative image takes an empty alt="" — the screen reader skips it instead of reading "image".

To caption an image, the pair <figure> / <figcaption> wraps the image and its caption:

<figure>
  <img src="cat.jpg" alt="A ginger cat asleep on a keyboard">
  <figcaption>Pixel, interrupted mid-typing.</figcaption>
</figure>

Finally: weight matters. A photo straight out of a camera often weighs 5 MB or more, an eternity to load. For the web, we resize and compress — you will see that in module 4.

Practice (30 min)

1. Find a photo of yours (or download a free image from Wikimedia Commons), copy it into your devweb folder under a simple name, with no spaces or accents: photo.jpg. Spaces and accents in file names are a classic source of broken images.
2. In article.html, insert the image inside a <figure> with its <figcaption> and an alt that truly describes it. Reload. Success criterion: the image displays with its caption.
3. Rename the image file on disk (without touching the HTML) and reload: the image is broken, and your alt text shows in its place. You have just seen what it is for. Repair the name.
4. Add a purely decorative image (a separator, a pattern) with alt="".
5. Read your two alt out loud, eyes closed: can you hear what each image brings?

Agent tips: "suggest three alt texts for this image: [describe the image]" is a good use. Trap: it cannot see the image unless you show or describe it — without a description, it invents. Proof: reread each alt with your eyes closed; you are the judge.

Recap (10 min)

Three lines: the two attributes of img, the three cases where alt saves the day, what figure is for. Then reinsert the complete figure without notes.

Day 8 — Block, inline, div and span

Goal: tell block elements from inline ones, and use div and span as neutral boxes.

Theory (20 min)

Every HTML element has a default display behavior. Block elements take the full available width and push the next one to a new line: p, h1…h6, ul, figure, table. Inline elements take only the space of their content and stay in the flow of text: a, strong, em, img. That is why a <strong> does not break its paragraph while a <p> inside a <p> is forbidden.

The nesting rule that follows: an inline element can live inside a block; a block should not live inside an inline.

Sometimes no tag carries the right meaning: you just want to group elements to style them together (module 2) or manipulate them together (module 3). Two neutral tags serve that, with no meaning of their own: <div>, the generic block box, and <span>, the generic inline box. They become useful with class or id attributes, which you will learn with CSS:

<div class="callout">
  <p>A group of elements to style together.</p>
</div>
<p>A word <span class="highlight">highlighted</span> inside the sentence.</p>

The temptation to make everything a div is strong. Resist: if a tag has the right meaning (a list is a ul, not three divs), it works for you — module 4 will show how much screen readers depend on it.

Practice (30 min)

1. In article.html, open the developer tools (F12), "Inspector" tab. Hover over your elements: the browser highlights their footprint. Success criterion: you can see that a <p> spans the full width while a <strong> only spans its word.
2. Group a heading and its paragraph inside a <div class="card">. Nothing changes visually: normal, the box is neutral until CSS arrives.
3. Wrap a word of a paragraph in a <span class="important">.
4. Try nesting a <p> inside a <strong>, reload, inspect: the browser reorganizes your code by itself. Look at the inspector, not your file: it tells the truth about what the browser understood.
5. Revalidate with the W3C: zero errors.

Agent tips: "here is my HTML and what the inspector shows differently — why?" pastes BOTH versions (your file + what the inspector shows). Trap: without the inspected version, it answers off-target. Proof: its explanation must match what you observe on reload.

Recap (10 min)

Three lines: block vs inline, the nesting rule, when to use div and span. Then list from memory five block tags and five inline tags.

Day 9 — Forms 1/2: text input

Goal: build a first form with a text field, a label and a button.

Theory (20 min)

The form is the first interactive element of the path: the user writes in it, and the page receives the input. The <form> tag wraps the fields. The most common field is <input type="text"> — an orphan tag whose type attribute decides the field's shape.

Every field needs a label: the visible text that says what is expected ("Your first name"). Connect it to the field by giving the field an id and the label a for attribute with the same value:

<form>
  <label for="firstname">Your first name</label>
  <input type="text" id="firstname" name="firstname">
  <button type="submit">Send</button>
</form>

This for/id link is no refinement: clicking the label places the cursor in the field (a comfort on mobile), and the screen reader announces "Your first name, edit text" instead of a silent field. A form without labels is a silent form.

The name attribute is the name under which the input will be sent. And what happens when you click "Send"? Without an action attribute, the form reloads the page and appends the input to the URL, visible in the address bar: ?firstname=Alice. Unspectacular, but it proves data flows — in module 3, JavaScript will intercept it before the reload.

Practice (30 min)

1. Create contact.html with the skeleton, and copy the form above by typing it by hand.
2. Open the page, click the words "Your first name": the cursor jumps into the field. Success criterion 1: this jump works — proof the for/id link is right.
3. Type a first name, click "Send". Success criterion 2: the page reloads and the address bar shows ?firstname=... with your input.
4. Add a "Your email" field of type email: the browser will refuse an input without @ on submit. Test with "hello" then with a real-looking address (with an @ and a dot): the field type is a first validation, free.
5. Remove the for of one label, reload, click the label: nothing happens anymore. Put it back. You can now diagnose a silent label.

Agent tips: "add an email field with its label to this form" is safe. Trap: it may pick different ids for the for and the field. Proof: clicking the label must place the cursor in the field — test it with your finger.

Recap (10 min)

Three lines: the role of form, the for/id pair, what the submit button does without an action. Then rewrite the form from memory.

Day 10 — Forms 2/2: checkboxes, radio buttons, dropdowns

Goal: use the other field types: checkbox, radio button, dropdown list and long text area.

Theory (20 min)

The type attribute of <input> is a toolbox. Today, four tools:

• type="checkbox": a tick box, for an independent yes/no ("I accept the charter"). Several can be ticked in the same form.
• type="radio": a single choice among several ("small / medium / large"). Radio buttons of the same group share the same name: this common name is what links them and guarantees only one is ticked. Each has its own value, the value sent.
• <select>: the dropdown list, containing <option>s. Space-saving when choices are many.
• <textarea>: a multi-line text area, for messages. Unlike input, it has a closing tag.

<fieldset>
  <legend>Size</legend>
  <label><input type="radio" name="size" value="s"> Small</label>
  <label><input type="radio" name="size" value="m"> Medium</label>
</fieldset>

<fieldset> groups related fields and <legend> gives the group's title — the screen reader announces "Size, group" then each option. Tag trick: an <input> written inside its <label> is linked without needing for/id.

Practice (30 min)

1. In contact.html, add a "Topic" fieldset with three radio buttons ("Question", "Idea", "Other") sharing name="topic".
2. Add a checkbox "I want an email reply" with its label.
3. Add a dropdown "How did you hear about me?" with three options, and a "Your message" textarea.
4. Success criterion: you can only tick one topic at a time (try ticking two: the first unticks itself), the checkbox toggles freely, and on submit the URL carries all your inputs with their names.
5. Change the name of one radio so it differs from the others: you can now tick two — proof that the common name makes the group. Repair it.

Agent tips: "add a group of three radios name='topic' to this form" — the agent knows the syntax by heart. Trap: it may give three different names, and the group is dead. Proof: try ticking two options, only one may stay.

Recap (10 min)

Three lines: checkbox vs radio, the role of the common name, when to prefer select. Then rewrite the fieldset from memory.

Day 11 — Tables

Goal: present tabular data with table, caption, th and td — and know when NOT to use a table.

Theory (20 min)

An HTML table presents tabular data: rows that share the same columns (a timetable, a ranking, a bank statement). Not for layout — that was the practice of the 1990s, it is dead, and the CSS of module 2 does it better.

The anatomy: <table> wraps everything; each row is a <tr> (table row); inside a row, each cell is a <td> (table data) — or a <th> (table header) if it is a header cell, which the browser bolds and which the screen reader announces before each cell of its column. A <caption> as first child gives the table's title:

<table>
  <caption>Club timetable</caption>
  <tr>
    <th>Day</th>
    <th>Time</th>
  </tr>
  <tr>
    <td>Tuesday</td>
    <td>6 pm</td>
  </tr>
</table>

For longer tables, group: <thead> for the header row, <tbody> for the data, <tfoot> for a possible total. Headers can state their scope with scope="col" (column header) or scope="row" (row header) — one more boost for screen readers.

Practice (30 min)

1. Create timetable.html and type the table above, then extend it to five data rows with your own schedule (classes, sports, work).
2. Add scope="col" to the two <th>, then split the table into <thead> and <tbody>.
3. Success criterion: the table displays with its caption, its bold headers, and the W3C validator reports no error.
4. Add a third "Place" column: one <th> in the header and one <td> in EVERY row — forget one and watch the row squeeze to the left. That is the classic table failure: a row shorter than the others.
5. Inspect the table in the developer tools to see how the browser arranged your rows.

Agent tips: "turn this schedule list into an HTML table with caption and th" is a good order — paste the raw data. Trap: it may drop a td on one row. Proof: count the cells per row in the rendered code, or check with the validator.

Recap (10 min)

Three lines: the anatomy table/tr/th/td, what caption and scope are for, when a table is the wrong tool. Then redo the table without notes.

Day 12 — Semantic HTML

Goal: structure a page with region tags: header, nav, main, section, article, footer.

Theory (20 min)

Since HTML5 (2008), the language offers tags that name the regions of a page instead of leaving everything in anonymous divs:

• <header>: the page header (logo, site title) or a section's;
• <nav>: a navigation block (the menu);
• <main>: the main content of the page — only one per page;
• <section>: a thematic part of the content, usually with its heading;
• <article>: a self-contained content that would make sense alone (a blog post, a product card);
• <aside>: side content (a callout, related links);
• <footer>: the page footer (legal, contact).

These tags change nothing visually — they are divs that speak. Their value is elsewhere: screen readers offer a "jump to main content" shortcut that skips the navigation (these regions are called landmarks), search engines tell content from decoration, and your code reads like an outline. Semantic simply means "carrying meaning".

Typical page structure:

<body>
  <header><h1>My site</h1></header>
  <nav><a href="index.html">Home</a></nav>
  <main>
    <section>
      <h2>News</h2>
      <article>...</article>
    </section>
  </main>
  <footer><p>© 2026</p></footer>
</body>

Practice (30 min)

1. Take index.html and restructure it: a <header> with the h1, a <nav> with links to your other pages, a <main> with the content, a <footer> with your name.
2. Inside main, wrap each topic in a <section> with its <h2>.
3. Success criterion: the inspector shows the header / nav / main / footer structure, and the page displays exactly as before — proof that semantics is not decoration.
4. Apply the same structure to article.html, where the main content will be an <article>.
5. Count your <main> per page: there must be exactly one.

Agent tips: "restructure this page with semantic tags, without touching the content" is a safe refactor. Trap: it may add two mains or move a paragraph. Proof: a single <main> in the render, and compare the displayed text before/after — identical to the word.

Recap (10 min)

Three lines: what "semantic" means, the role of landmarks, the single-main rule. Then list the seven region tags from memory.

Day 13 — Mini-project: your personal page

Goal: assemble the whole module into one complete personal page, with no step-by-step guide.

Theory (20 min)

Today, no new notion: you consolidate. A personal page presents who you are, what you do, how to reach you. The specification:

• complete skeleton with lang, charset and title;
• semantic structure: header, nav, main, footer;
• a single <h1>, sections with <h2>;
• at least one list (bulleted or numbered);
• at least one image with a careful alt;
• links: to your other path pages, and one external;
• a small contact form with linked labels;
• an HTML comment dating the page.

Working method, the same as professionals: first draft the outline on paper (which sections?), then the skeleton, then fill section by section, reloading often. Nobody writes a whole page before looking at it.

Practice (30 min)

1. On paper, sketch your page's plan: which sections, in which order.
2. Create me.html and build it alone, with no step-by-step. Stuck for more than five minutes? Reread the session of the sticking point, then come back.
3. Success criterion: every point of the specification is present, and the W3C validator says "no errors".
4. Show the page to someone (or read it out loud): every link works, every image displays, the form accepts input.

Agent tips: resist "write my personal page": that is precisely the exercise. The right order, at the end: "proofread this page as an HTML reviewer and list the problems, without fixing them". Proof: each problem quoted with its line, and you do the fixing.

Recap (10 min)

Three lines: what took you the longest, the error you hunted the longest, what you are happy with. This page will become your site's home page in module 4.

Day 14 — Module 1 review

Goal: check that the whole module is acquired, and fill the gaps before CSS.

Theory (20 min)

Reread your notebooks of the past thirteen days. Then test yourself, without notes:

1. Tell the journey of a web request, from URL to display.
2. Write the complete HTML skeleton on a blank sheet.
3. Name the three kinds of links and their syntax.
4. Explain the difference between <strong> and <b>.
5. Explain how a label connects to its field, and why it matters.
6. Name five semantic tags and their role.
7. Draw the anatomy of a table: table, caption, tr, th, td.

Each question that resists points to a session to redo — redoing a session costs an hour, dragging a doubt costs a module.

Practice (30 min)

1. Take the seven-question test above, in writing, without notes.
2. For each failed question: redo the practice of the matching session.
3. Success criterion: seven right answers, or the missing sessions redone. Both are successes.
4. Tidy your devweb folder: a module1 folder holding index.html, article.html, contact.html, timetable.html, me.html and your images. One clean folder per module — you will thank yourself in module 4.

Agent tips: "quiz me on HTML, one question at a time, from basic tags to forms; wait for my answer before correcting, and keep my errors to re-ask them at the end" makes a perfect examiner. Trap: it grades gently unless you force it to compare with the course. Proof: its corrections must quote the exact rule.

Recap (10 min)

Three lines: your three strongest skills, and the notion you will watch in module 2. Tomorrow: CSS, and your pages get colors.