Learn how the web works and build, style and publish your own responsive website with semantic HTML and modern CSS.

HTML & CSS Foundations

## Why this matters

Every web page you will ever build travels the same road: a browser asks for it, a server sends it, and the browser turns it into something you can see and use. When a page is slow, broken or blank, the cause is almost always somewhere on that road. If you can picture each step, you can find the problem instead of guessing.

This lesson walks the road once, slowly. You do not need to memorise every detail; you need a mental model you can come back to.

## The two sides: client and server

- The **client** is the program asking for something. For the web, that is usually a browser such as Firefox, Chrome, Safari or Edge, running on your laptop or phone.
- The **server** is a computer, somewhere on the internet, running a program that listens for requests and answers them.

A server is not a special kind of machine. It is any computer running server software. During this course your own laptop will act as both: the browser is the client, and when you open a file or run a local server, your machine plays the server too.

## Step 1: you type a URL

A URL (Uniform Resource Locator) is an address. Take this one apart:

```text
https://www.example.com:443/blog/post.html?lang=en#comments
```

| Part | Example | Meaning |
|---|---|---|
| scheme | `https` | which protocol to speak (HTTPS = HTTP over an encrypted connection) |
| host | `www.example.com` | which server to contact |
| port | `443` | which "door" on that server (443 is the default for HTTPS, so it is usually hidden) |
| path | `/blog/post.html` | which resource on that server |
| query | `?lang=en` | extra options sent to the server |
| fragment | `#comments` | a spot inside the page; it never leaves your browser |

## Step 2: DNS turns the name into a number

Computers on the internet find each other by **IP address**, such as `93.184.215.14` or a longer IPv6 address. Names like `www.example.com` exist for humans. The browser asks the **Domain Name System (DNS)** to look the name up, much like looking up a contact to get a phone number. The answer is cached, so the second visit skips most of this step.

## Step 3: a connection opens

With the IP address in hand, the browser opens a connection to the server (TCP, or QUIC for newer HTTP/3). For `https` URLs, the two sides also perform a **TLS handshake**: the server proves its identity with a certificate, and they agree on keys so nobody in between can read or change the traffic. That is what the padlock in the address bar means.

## Step 4: the browser sends an HTTP request

Now the browser speaks HTTP, a plain-text protocol (you will read real messages in the next lesson). The request says, in effect: "Please GET `/blog/post.html` from `www.example.com`. I understand HTML, and I prefer English."

## Step 5: the server responds

The server finds or builds the resource and sends back an **HTTP response**: a status code (such as `200 OK` or `404 Not Found`), some headers describing the content, and the content itself, here an HTML document.

Some servers just read a file from disk. These are **static** sites, and you will publish one at the end of this course. Others run code that builds each page on the fly from a database; those are **dynamic** sites. To the browser both look the same: it receives HTML.

## Step 6: the browser renders the page

This is where HTML and CSS come in.

1. **Parse HTML into the DOM.** The browser reads the HTML from top to bottom and builds the **Document Object Model**, a tree of elements (`html` contains `head` and `body`, `body` contains headings, paragraphs, and so on).
2. **Fetch more resources.** Along the way it finds references to stylesheets, images, fonts and scripts, and sends a new request for each one. A single page often needs dozens of requests.
3. **Apply CSS.** It parses the CSS and works out the final style of every element.
4. **Layout.** It calculates where every box goes and how big it is, based on the screen size.
5. **Paint.** It draws pixels: text, colours, borders, images.

If JavaScript changes the page later, the browser repeats some of these steps for the parts that changed.

## Worked example: watching it happen

You can see every request your browser makes.

1. Open any website, then open the developer tools (F12, or right-click and choose **Inspect**).
2. Choose the **Network** tab and reload the page.
3. The first row is usually the HTML document. Click it to see the request URL, the status code and the response headers.
4. Below it, notice the stylesheets, images and scripts the HTML asked for, each with its own status and size.

Try a URL that does not exist on a site, such as `/this-page-is-not-real`. The first row now shows status `404`. The server still answered; it just answered "not found".

## Common mistakes

- **Thinking the URL is the file.** The path often maps to a file, but a server can answer any path however it likes.
- **Blaming the HTML for a DNS or network problem.** "This site can't be reached" means the browser never got a response at all, so your markup is not the issue yet.
- **Forgetting that every image, font and stylesheet is another request.** Large or numerous files are the most common reason a simple page feels slow.
- **Expecting the fragment (`#comments`) to reach the server.** It stays in the browser and only scrolls the page.

## Quick recap

- The browser (client) asks; the server answers.
- URL, then DNS lookup, then a connection (with TLS for HTTPS), then an HTTP request and response.
- The browser parses HTML into the DOM, fetches extra resources, applies CSS, lays out boxes and paints pixels.
- The Network tab in developer tools shows every request and its status.

## Try it

Open the **Do** tab for a short quiz on the journey of a page load.


Follow a web page from the moment you press Enter to the pixels on your screen.

Browsers, servers, and the request

How The Web Works - The Big Picture

How Websites Work | simply explained with examples

## Why this matters

HTTP (HyperText Transfer Protocol) is the language browsers and servers speak. As a front-end developer you will read HTTP messages in the Network tab every week: to see why an image will not load, why a form submission failed, or why an old version of your stylesheet keeps showing up. The good news is that HTTP messages are plain text with a simple, fixed shape.

## The shape of a request

Here is a request a browser might send:

```http
GET /blog/post.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0) Firefox/131.0
Accept: text/html
Accept-Language: en-GB,en;q=0.8
```

1. **Request line:** the method (`GET`), the path (`/blog/post.html`) and the protocol version.
2. **Headers:** one `Name: value` pair per line, describing the request. `Host` says which site you want, because one server can host many sites. `Accept` says which formats the browser understands.
3. **A blank line**, then an optional **body**. A `GET` has no body; a form submission with `POST` carries the form data here.

## The shape of a response

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Cache-Control: max-age=600

<!DOCTYPE html>
<html lang="en">
  ...
</html>
```

1. **Status line:** the version, a **status code** (`200`) and a short reason (`OK`).
2. **Headers:** `Content-Type` tells the browser what the body is (HTML here, encoded as UTF-8). `Cache-Control` says the browser may reuse this copy for 600 seconds.
3. **A blank line**, then the **body**: the HTML document itself.

Newer versions of HTTP (HTTP/2 and HTTP/3) send the same information in a compact binary form, but developer tools show it to you in this readable shape, and the meaning is identical.

## Methods: what you want to do

| Method | Typical use | Has a body? |
|---|---|---|
| `GET` | Fetch a page, image or data | No |
| `POST` | Submit a form, create something | Yes |
| `PUT` / `PATCH` | Replace / update something | Yes |
| `DELETE` | Remove something | Usually no |

A plain link or typing a URL always sends `GET`. An HTML form sends `GET` by default, or `POST` when you write `method="post"`. Rule of thumb: `GET` should never change anything on the server, which is why browsers happily repeat it, cache it and prefetch it.

## Status codes: how it went

The first digit tells you the category:

| Range | Meaning | Common examples |
|---|---|---|
| 1xx | Informational | rare in day-to-day work |
| 2xx | Success | `200 OK`, `201 Created`, `204 No Content` |
| 3xx | Redirect: look elsewhere | `301 Moved Permanently`, `302 Found`, `304 Not Modified` |
| 4xx | Client error: the request was wrong | `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `429 Too Many Requests` |
| 5xx | Server error: the server failed | `500 Internal Server Error`, `502 Bad Gateway`, `503 Service Unavailable` |

The split between 4xx and 5xx is the most useful thing to remember. A 4xx says "change your request"; a 5xx says "the server has a problem, and retrying later may help".

A redirect response carries a `Location` header with the new URL, and the browser follows it automatically. That is how `http://` addresses end up on `https://`.

## Headers worth knowing

- `Content-Type`: what the body is (`text/html`, `text/css`, `image/png`, `application/json`). A stylesheet served as `text/plain` is ignored by the browser.
- `Cache-Control`: how long the browser may reuse a response. Long caching is why you sometimes need a hard reload (Ctrl+Shift+R or Cmd+Shift+R) to see your latest CSS.
- `Set-Cookie` (response) and `Cookie` (request): HTTP itself is **stateless**, meaning each request stands alone. Cookies let a site remember you between requests, for example to keep you logged in.
- `Location`: where a redirect points.

## Worked example: reading the Network tab

Open developer tools, choose **Network**, and reload a page. Click the first row (the document) and look at **Headers**:

- *General* shows the request URL, the method (`GET`) and the status code (`200`).
- *Response headers* show `content-type: text/html; charset=utf-8` and usually a `cache-control` value.
- *Request headers* show what your browser sent: `accept`, `accept-language`, `user-agent`.

Now find an image row. Its `content-type` is something like `image/webp`. If you ever see an image row in red with `404`, the `src` path in your HTML is wrong: a very common beginner bug that the Network tab reveals in seconds.

## Common mistakes

- **Treating every error as "the server is broken".** A 404 or 403 usually means the request (often your URL or path) needs fixing.
- **Using GET to change data.** Search engines and browsers may repeat GET requests; anything that deletes or buys should be POST (or another non-GET method).
- **Ignoring the cache.** If your change "did not work", check whether the browser is still using a cached copy.
- **Assuming HTTP is private.** Plain `http://` traffic can be read in transit; use `https://`.

## Quick recap

- A request is a method, a path, headers and an optional body. A response is a status code, headers and a body.
- 2xx success, 3xx redirect, 4xx your request is wrong, 5xx the server failed.
- `Content-Type` describes the body; `Cache-Control` explains stale files; cookies add memory to a stateless protocol.

## Try it

Open the **Do** tab for a quiz where you read requests and responses and decide what happened.


Read a real HTTP request and response: methods, headers, status codes and bodies.

HTTP in 5 minutes

HTTP Crash Course & Exploration

Learn HTTP Status Codes In 10 Minutes

## Why this matters

HTML (HyperText Markup Language) is the first thing the browser receives and the skeleton every other technology hangs on. CSS styles HTML elements; JavaScript reads and changes them; screen readers and search engines read their meaning. If the HTML is muddled, everything built on top of it is harder.

## Markup describes meaning, not looks

HTML is a **markup** language, not a programming language. It has no loops or variables. Instead, you wrap pieces of content in **tags** that say what each piece *is*:

```html
<h1>Trail Running Club</h1>
<p>We meet every Saturday at 8am.</p>
```

The `<h1>` says "this is the main heading of the page". It does not say "make this big and bold". Browsers do show headings large by default, but that is just a default style that you will replace with CSS. Choose tags by meaning, then style them however you like.

## Elements, tags and nesting

An **element** is usually an opening tag, some content and a closing tag:

```html
<p>This is a <strong>very</strong> short paragraph.</p>
```

- `<p>` opens the paragraph and `</p>` closes it.
- `<strong>` is nested **inside** the paragraph and closed before the paragraph closes. Elements nest like boxes inside boxes; they never overlap.
- A few elements are **void** (empty) and have no closing tag, such as `<meta>`, `<img>`, `<br>` and `<input>`.

Tag names are not case-sensitive, but lowercase is the universal convention.

## The minimal valid document

Every HTML page should start from this skeleton:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Trail Running Club</title>
</head>
<body>
  <h1>Trail Running Club</h1>
  <p>We meet every Saturday at 8am.</p>
</body>
</html>
```

Line by line:

- `<!DOCTYPE html>` tells the browser to use modern standards mode. Without it, browsers fall back to "quirks mode", which imitates old browser bugs and makes CSS behave strangely.
- `<html lang="en">` is the root element. The `lang` attribute tells screen readers which pronunciation to use and helps translation tools.
- `<head>` holds information **about** the page that is not shown in the page itself.
- `<meta charset="utf-8">` declares the character encoding so accented letters, symbols and non-Latin scripts display correctly. Put it first in the head.
- `<meta name="viewport" ...>` makes phones show the page at its real width instead of a zoomed-out desktop view. You will rely on it in Module 4.
- `<title>` is the text in the browser tab, in bookmarks and in search results. Every page needs a short, specific title.
- `<body>` holds everything the visitor actually sees.

## Browsers forgive, but do not rely on it

If you forget a closing tag or leave out `<head>`, the browser quietly repairs the document using rules defined in the HTML standard. That forgiveness is why broken HTML often *looks* fine. But the repaired tree may not be what you meant, and CSS or JavaScript that targets it can misbehave. The **W3C Markup Validation Service** (validator.w3.org) checks your document and lists every error, with line numbers. Running it is a habit worth building now.

## Worked example: inspecting the DOM

Save the skeleton above as `index.html` and open it in your browser (double-click the file, or drag it into a browser window). Now right-click the heading and choose **Inspect**. The Elements panel shows the **DOM tree** the browser built: `html` with `head` and `body` inside, and your heading and paragraph inside `body`.

Delete the `<!DOCTYPE html>` line, reload, and type `document.compatMode` into the **Console** tab. It now says `"BackCompat"` (quirks mode). Put the doctype back, reload, and it says `"CSS1Compat"` (standards mode). That one line changes how the whole page is interpreted.

## Comments

Notes for humans go inside comments, which browsers ignore:

```html

```

Anyone can read comments with "View source", so never put passwords or private notes in them.

## Common mistakes

- **Choosing tags for their look.** Using `<h3>` because it is "the right size" breaks the outline of the page; pick the right level and adjust the size with CSS.
- **Overlapping tags** such as `<p><strong>text</p></strong>`. Close the inner element first.
- **Missing doctype or charset**, which leads to quirks mode or garbled characters.
- **Content in the head.** Visible content belongs in `<body>`.
- **A generic title** like "Untitled" or "Home". Titles are what people see in tabs and search results.

## Quick recap

- HTML marks up meaning: you choose tags for what content is, not how it looks.
- Elements nest; void elements like `<meta>` and `<img>` have no closing tag.
- Every page starts with a doctype, `<html lang>`, a head with charset, viewport and title, and a body.
- Validate with validator.w3.org; inspect the DOM with developer tools.

## Try it

Open the **Do** tab. The starter document works in the browser but is missing several required parts. Turn it into a valid, minimal document.