0–5 min Recall
Without notes, state yesterday’s main idea and one unresolved question.
HTML document structure
HTML, CSS, Git, and the First Website
Objective
Create valid pages with meaningful structure.
HTML is the mechanical structure, CSS is the physical layout and finish, and Git is the revision history for every design change.
- doctype, html, head, body
- headings and paragraphs
- semantic landmarks
Why this matters
Today you write your first code. By the end you will have a real web page — a file on your disk that a browser opens and renders — and you will be able to name every line in it.
The page you start today grows all week into a published website. Get the structure right now and everything after it becomes easier, because structure is what the rest attaches to.
What HTML actually is
HTML stands for HyperText Markup Language. It is not a programming language — it has no decisions and no loops. It marks up text to say what each part is: this is a heading, this is a paragraph, this is the navigation.
The unit of markup is an element. Most look like this:
<p>An electronics engineer learning to build software.</p>
Three parts: an opening tag <p>, the content, and a closing tag </p> with a slash.
Elements nest inside each other, which is how a page gets a shape — a tree, exactly like the
folder tree from Day 3.
Some tags carry attributes: extra information written inside the opening tag as name="value".
In <html lang="en">, the attribute lang="en" tells browsers and screen readers that this page
is in English. A few elements have no content and so no closing tag — <meta> and <img> are the
ones you meet first.
Markup is a schematic, not firmware
A schematic does not do anything. It declares what exists and how parts connect, and every tool downstream — layout, BOM, test fixture — reads meaning out of that declaration. HTML works the same way: it declares what exists, and the browser, the screen reader, and search engines each read meaning out of it.
The skeleton every page has
Every HTML file starts with the same four things. Here they are, with nothing else:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>My page</title>
</head>
<body>
<p>Hello.</p>
</body>
</html>
<!doctype html>is not an element. It tells the browser "render this using modern standards." Leave it out and browsers fall back to a 1990s compatibility mode where sizing and spacing behave strangely. It always goes first, on its own line.<html lang="en">wraps everything else. It is the root of the tree.<head>holds information about the page that is not displayed: the character encoding, the title, links to stylesheets later this week.<body>holds everything the visitor actually sees.
<meta charset="utf-8" /> says the file is encoded as UTF-8, which is what makes accented letters,
°, and Ω display instead of garbled symbols. <title> sets the browser tab text, and it is what a
search result or bookmark shows.
A letter in an envelope
The <head> is the envelope — address, postage, handling instructions. The <body> is the
letter inside. The postal system reads the envelope; the person reads the letter. Not
interchangeable.
Headings and paragraphs
<h1> through <h6> are headings, <h1> being the most important. <p> is a paragraph.
Headings are not font sizes. They are an outline. A browser happens to render <h1> large, but
that size is a side effect you will override with CSS on Day 11. Two rules keep the outline
honest: one <h1> per page — the page's actual subject — and never skip levels.
This matters because assistive technology uses the outline for navigation. A screen reader is
software that reads a page aloud for someone who cannot see it, and it lets the user jump heading
to heading — the equivalent of your eye skimming for a bold line. Choosing <h4> because it
"looked the right size" corrupts that outline for everyone using it.
Semantic landmarks
A semantic element is one whose name states its meaning. <div>Navigation</div> and
<nav>Navigation</nav> render identically, but only the second says what it is. <div> is a
generic box with no meaning at all.
The landmark elements you need today:
| Element | Means |
|---|---|
<header> |
Introductory content — title, tagline, logo |
<nav> |
A block of navigation links |
<main> |
The main content of this page. One per page |
<section> |
A thematic grouping, which should have a heading |
<article> |
Self-contained content that makes sense elsewhere too |
<footer> |
Closing content — authorship, contact, copyright |
Why bother, when they look the same? Because a page is read by more than one kind of reader.
Semantic HTML communicates the page's structure to browsers and assistive technology. A screen
reader can announce "banner, navigation, main" and jump straight to <main>, skipping the
repeated header. Reader mode uses it to find the article; search engines use it to work out what
the page is about. Replace them all with <div> and every one of those readers is left guessing
from visual cues that some of them cannot see at all.
Labelled connectors vs flying leads
Two boards joined by unlabelled flying leads work fine on your bench, because you remember which
is which. Fit a keyed, labelled connector and the next technician can service it without you in
the room. <div> is a flying lead; <nav> is a labelled connector.
Walkthrough: your first page
Open your terminal in fullstack-journey (Day 3), then:
mkdir profile-site
cd profile-site
touch index.html
index.html is the conventional filename for a site's entry page — Day 14 depends on it. Open the
folder in VS Code and type this in:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Profile — Electronics Engineer</title>
</head>
<body>
<header>
<h1>Your Name</h1>
<p>Electronics engineer learning full-stack development.</p>
</header>
<main>
<section>
<h2>About</h2>
<p>I design and test embedded hardware, and I am building web tools for it.</p>
</section>
</main>
<footer>
<p>Written by hand, no generator.</p>
</footer>
</body>
</html>
Save it, then open it: double-click the file, or drag it onto your browser. The address bar shows
file:///... — a local file, no server involved. You saw servers on Day 5; you do not need one
yet. That second <meta> line tells mobile browsers to use the real device width instead of
pretending to be a desktop. It does nothing visible today and everything on Day 12.
Prove the semantics are really there
Open DevTools (Day 6) and look at the Elements panel: that is the tree the browser built
from your file. Find the Accessibility pane in that panel and select <main> — the browser
reports its role. That role is what a screen reader announces, and it came from the tag name,
not from anything you styled.
Your turn
Extend index.html into a header, a main with two sections, and a footer.
- Keep the
<header>. Add a<nav>inside it — real links come tomorrow, so<nav><a href="index.html">Home</a></nav>is enough for now. - Inside
<main>, keep the About<section>and add a second one with<h2>Projects</h2>and a paragraph describing one project. - Give every
<section>a heading, and check your outline readsh1, thenh2,h2— no skips. - Put something real in the
<footer>: your name and the year. - Save, refresh, and confirm all four regions appear in the order you wrote them.
- Validate it: go to
validator.w3.org, choose Validate by File Upload, uploadindex.html, and fix what it reports until the document has no errors.
You are done when
The validator reports no errors, and you can point at each of <header>, <nav>, <main>,
<section>, <footer> and say in one sentence why that tag and not a <div>.
Tutor mode, after you have written the page yourself
Today's AI mode is tutor: ask for an explanation, then a small example, then attempt it yourself. Never ask for the finished answer — code you did not write is code you cannot debug.
"Explain every tag in my page and ask me what would break semantically if I replaced it with div."
Answer its questions before reading the explanation.
Common pitfalls
- Forgetting the closing tag.
<section>without</section>swallows everything after it. The validator catches this instantly; guessing does not. - Choosing headings by size. If
<h2>looks too big, that is a CSS problem and Day 11 fixes it. Never pick a level for appearance. <div>for everything.<div>is fine for grouping purely for style, but where a meaningful element exists, that one is correct.- Saving as
index.html.txt. Hidden extensions cause this (Day 3). The symptom is the browser showing your raw code as text.
Verify it yourself
Open today's reference, MDN's Structuring content with HTML, and find its page on document structure and semantics.
- MDN covers a landmark this lesson skipped —
<aside>. Read its definition and decide, in one sentence, whether anything on your page belongs in one. - Find MDN's statement about why semantic elements help assistive technology. Does it agree with the claim made above?
Write both answers into notes/day-08.md. Checking a lesson against the specification is the
habit that outlives any single tag.
The hour
-
- 5–20 min Learn
Read only the listed concept notes and official reference sections needed today.
- 20–48 min Build
Create index.html with header, main, two sections, and footer. Use meaningful headings.
- 48–55 min Explain and verify
Run the result, inspect evidence, and explain the data/control flow in your own words.
- 55–60 min Quiz and commit
Complete the quiz, record one lesson, and commit the verified change when applicable.
What to hand in
Deliverable
A valid semantic page that opens directly in the browser.
Working with AI today
AI as tutor
Ask for explanations, analogies, questions, and hints. Do not request a complete finished solution first.
Explain every tag in my page and ask me what would break semantically if I replaced it with div.
References
End-of-day quiz
Explain-back gate
Pass the quiz above to unlock completion.
Quiz + explain-back checks required.