Unit 01 · open to everyone
The Internet
By the end of this unit you can trace a page from a typed domain to a rendered document, and you've written, structured, and styled a real HTML page of your own.
A web page is a document, sent somewhere, by something that agreed to send it. This unit covers all three: how a typed domain finds a real machine, what that machine sends back, and how to write a document worth sending. By the end you’ll have built and styled a page of your own.
How information moves
Type a domain and press enter, and five things happen before anything appears on screen.
Keep scrolling
You type a domain. Not an address — a name. gilmour.online means
nothing to a router; it has to become a number first.
The browser asks a resolver. “Who is this?” goes out to a DNS server before anything else can happen — DNS is the Internet’s phone book, and every request starts by opening it.
The resolver answers with a record. An A record routes an apex
domain to an IP address. A C record routes a subdomain to another
name. An MX record routes mail — which is why @gilmour.org mail and
gilmour.org web can live on entirely different servers.
The browser requests the page. Now that it has an address, it opens a
connection and asks for something specific — GET /, the front door.
The server answers. 200 OK and a document follow. Everything after
this point in the unit is about what that document should say.
Try it yourself: pick a domain you use daily and look up its records with a
public tool (whatsmydns.net or your terminal’s dig). Report what you find
— which record type answered, and what it points at.
Where the Internet came from
The Internet wasn’t built by a company. ARPANET, its ancestor, was a government research network with one design goal worth remembering: no single point of failure. That goal — a network nobody fully owns and nobody can fully break — is also the reason the question below doesn’t have an easy answer.
Writing to a client
Before you write a line of HTML, you’ll write an email — because the first real deliverable of most web work is a message, not a page. State your purpose, your ask, and your deadline. Leave any one of those out and the email becomes unanswerable: no subject, a buried ask, or no deadline at all.
Add this question to
Loading your meetings…
A client emails: 'Hey, following up on that thing — let me know!' What makes this unanswerable?
A professional email states its purpose, its ask, and its deadline. Missing any one of those pushes the work of figuring out what's actually needed back onto the reader.
The request/response cycle
You already traced how a browser finds a server. What happens next is a strict split: the server sends HTML. The browser builds the page from it. Nothing about layout, color, or interactivity travels over the wire as a picture — it travels as text, and your browser is the thing that turns that text into what you see. That split is why the next section matters: the text you write is the entire instruction set.
Anatomy of a document — writing your first page
Every HTML page starts the same five pieces, in the same order:
<!DOCTYPE html>
<html>
<head>
<title>My Page</title>
</head>
<body>
<!-- everything a visitor sees goes here -->
</body>
</html>
The vocabulary matters, because you’ll use it constantly: a tag is the
<opening>/</closing> syntax; an element is the kind of object the tag
builds; contents are what sits between the tags; an attribute is the
property="value" pair inside the opening tag. And the single most important
element on any page is still the hyperlink — write link text that describes
where it goes, not “click here.”
You haven’t set up a local editor yet — that’s Unit 4. For now, write and see a page render without installing anything:
Not sourced yet: a real starter Pen (the minimal boilerplate above, editable live) needs to be created and linked here before this ships. See gilmour-standards.md Part 6.
art wanted Meaning before appearance
Choose the element that describes what content is — heading, list, nav,
article — rather than the one that happens to look right. A <div> styled to
look like a heading is still, to every screen reader and search engine, an
anonymous box. And keep your headings in order: a page that jumps from h1
to h3 has a skipped level, and skipped levels break the outline a reader
who can’t see the page relies on.
Add this question to
Loading your meetings…
You're marking up a list of navigation links at the top of a page. What should wrap them?
The element you choose is a claim about what the content is, not just how it should look. Meaning before appearance is the whole point of this topic.
CSS as a separate concern
The rules that make a page look like something don’t belong inside the HTML that gives it meaning — they belong in their own file, linked in, so the same markup can be restyled without being rewritten:
<link rel="stylesheet" href="styles.css" />
Selectors decide which rule wins when more than one could apply. An id
selector beats a class selector, which beats an element selector; inline
styles beat all three; between rules of equal specificity, the later one
wins; !important overrides specificity and is the last resort, never the
first.
That’s the arc of this unit: a page is a document (anatomy), that means something before it looks like anything (semantics), styled last and separately (CSS). Unit 2 picks up from here — building your own CSS helper classes before meeting a framework that hands you a library of them.
Where you are
Not startedAnswer the checks above whenever you like. They're not graded, and you can retry any of them.
Kept in this browser only, unless you sign in.
Signing in carries this — and everything else you've done here — onto any device, and keeps it if you clear this browser.
Sources
- Gilmour Academy — Intro to Web Design