Polish and ship: your page goes live

Right-click any element on any page and choose Inspect. Devtools shows you the DOM - the structure the browser actually built, not the source you wrote. When those two disagree (an unclosed tag the browser repaired, a paragraph that swallowed its neighbor), the inspector is where the disagreement becomes visible.

• Hover a line in the inspector and the matching element highlights on the page - that is how you find "which tag is this box".
• Look for elements nested somewhere strange. If your footer appears inside your form in the inspector, the browser repaired a mistake and guessed wrong.

Go to validator.w3.org, pick "Validate by File Upload" (or paste your source under "Direct Input"), and submit. It reads your file with zero forgiveness and lists every technical sin with a line number.

• Read errors top-down and fix the FIRST one first. One unclosed tag early in the file confuses the parser about everything after it - the first error often causes half the list. Fix it, re-validate, watch ten errors become two.
• Warnings are advice, errors are bugs. Ship with zero errors; read the warnings and decide.

<h2>My skills</h2>
<p>Things I use <strong>every week.</p>
<ul>
  <li>Spreadsheets</li>
  <li>Python
  <li>SQL</li>
</ul>
<p>Always learning more.

Phone browsers assume old pages were designed for desktop, so by default they render your page on a fake 980px-wide canvas and shrink the whole thing down - tiny unreadable text, pinch-zoom everywhere. One line in the head tells the phone to stop pretending:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport"
          content="width=device-width, initial-scale=1">
    <title>Phoebe Fu</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <h1>Ready to ship</h1>
  </body>
</html>

• width=device-width - "use the phone's real width, not the fake 980px".
• initial-scale=1 - "start at 100% zoom, no shrinking".
• Test before shipping: open devtools, click the little phone icon (device mode), pick a phone size. If your page needs sideways scrolling at phone width, fix that before it meets a real phone.

When a page looks wrong, check in this order - cheapest first: 1) Did you save and reload? 2) Validator - unclosed tags and typos surface instantly. 3) Inspector - is the DOM shaped the way you think it is? 4) Only then suspect your CSS. In practice, steps 1 and 2 catch most of it; MDN's Debugging HTML lesson walks the same route with a deliberately broken demo file worth playing with.

Four checks you can run by reading your own source. Each one is a promise your markup makes to someone who is not looking at the screen:

• 1 · Every img has honest alt. Describe what the image shows and why it is there: alt="Phoebe presenting at a data meetup", not alt="photo". Purely decorative image? alt="" tells screen readers to skip it - honestly.
• 2 · Headings form a ladder. One h1, then h2, then h3 - no skipping down. Screen-reader users navigate by the headings list; a skipped level is a missing stair.
• 3 · Links say where they go. Read only the link text aloud: would you know the destination?
• 4 · Every input has a label wired with for matching the input's id - Session 4's rule, now audited.

<img src="https://placehold.co/80x80" alt="image">
<p>My talk slides are online -
  <a href="https://example.com/slides">click here</a>.</p>
<form>
  Your email <input type="email">
</form>

• 5 · Color contrast. Body text needs at least a 4.5:1 contrast ratio against its background. Do not trust your eyes on your own monitor - paste your two hex colors into the WebAIM contrast checker and let it judge.
• 6 · The lang attribute. <html lang="en"> has been on your page since Session 1 - confirm it survived your edits. It picks the screen-reader voice and the translation source language.

<p style="color: #b3b3b3;">
  Faint text feels elegant on your monitor
  and disappears on a phone in sunlight.
</p>

• Account: sign up free at github.com. Your username becomes part of your URL - pick one you are happy saying out loud.
• Repo: click New repository and name it exactly USERNAME.github.io (your real username) - that magic name publishes at the root URL. Any other repo name works too via Settings, it just lives at username.github.io/repo-name/.
• Upload: in the repo, "uploading an existing file" - then drag index.html, styles.css, and your images/ folder straight from your file manager into the browser. Commit (that is GitHub's word for "save").
• Switch: Settings → Pages → under "Build and deployment" choose Deploy from a branch, pick main, save. Your URL appears at the top of that page.
• Wait: first publish can take a few minutes. Refresh the URL, not your patience.

Why index.html mattered all course: when someone visits username.github.io, the server looks for a file named exactly index.html and shows it. That default was set in Session 1 and pays off today.

• Updating: edit the file locally, then upload it again with the same name - GitHub replaces the old one. Give it a minute, hard-refresh, done.
• Adding pages: upload about.html and it is live at username.github.io/about.html - your Session 2 links between pages now work on the real internet.