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

Flexbox arranges items along one line. Many layouts are two-dimensional: a header across the top, a sidebar and main area side by side, a footer at the bottom, or a gallery of tiles in rows *and* columns. **CSS Grid** is built for that. It lets you describe the whole layout on the parent, in a way that reads almost like a drawing.

## The core idea: tracks on the container

```css
.gallery {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 1rem;
}
```

- `display: grid` makes the element a **grid container**; its direct children become **grid items**.
- `grid-template-columns` defines the column **tracks**. Here: three equal columns.
- Items flow into the cells automatically, left to right, then onto the next row.
- `gap` sets the space between rows and columns.

## The fr unit

`fr` means "a fraction of the remaining space". After fixed tracks and gaps are subtracted, the leftover space is shared in proportion:

```css
grid-template-columns: 200px 1fr;     /* fixed sidebar, flexible main area */
grid-template-columns: 2fr 1fr;       /* main area twice as wide as the side */
grid-template-columns: repeat(4, 1fr); /* four equal columns */
```

`repeat(4, 1fr)` is shorthand for `1fr 1fr 1fr 1fr`.

## Template areas: drawing the layout

For page layouts, name the regions and draw them as a map:

```css
.page {
  display: grid;
  grid-template-columns: 200px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header  header"
    "sidebar main"
    "footer  footer";
  min-height: 100vh;
}

.site-header { grid-area: header; }
.sidebar     { grid-area: sidebar; }
.content     { grid-area: main; }
.site-footer { grid-area: footer; }
```

- Each quoted string is one row; each word is one column cell.
- Repeating a name (`"header header"`) makes that area span both columns.
- `grid-template-rows: auto 1fr auto` sizes the header and footer to their content and gives the middle row the remaining height, so with `min-height: 100vh` the footer sits at the bottom of the screen even on a short page.
- Each item claims its area with `grid-area`.

Areas must form rectangles; an L-shaped area is invalid and the whole template is ignored. A `.` in the map leaves a cell empty.

## Placing items by line number

Grid lines are numbered from 1 at the start edge. You can place an item across lines directly:

```css
.feature {
  grid-column: 1 / 3;    /* from line 1 to line 3: spans two columns */
  grid-row: 1;           /* first row */
}
.banner {
  grid-column: 1 / -1;   /* -1 is the last line: full width */
}
```

Template areas are easier to read for whole pages; line numbers are handy for one special item inside a gallery.

## Worked example: a gallery with no media queries

```css
.gallery {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(150px, 1fr));
  gap: 1rem;
}
```

Read it from the inside out:

- `minmax(150px, 1fr)`: each column is at least 150px and at most an equal share of the space.
- `repeat(auto-fit, ...)`: create as many columns as fit.

On a 1,000px-wide area you get six columns; on a 350px phone you get two; at 300px, one. The tiles reflow by themselves. This single line is one of the most useful patterns in modern CSS.

## Grid or Flexbox?

| Use Grid when | Use Flexbox when |
|---|---|
| you control rows **and** columns | items flow in one row or column |
| the layout comes first and content fills it | the content size comes first |
| page skeletons, galleries, dashboards, forms in columns | nav bars, toolbars, button groups, centring |

They work together: a grid page whose header uses Flexbox for its nav is completely normal.

## Inspecting a grid

In Chrome, Edge and Firefox developer tools, a small **grid** badge appears next to grid containers in the Elements panel. Click it to overlay the line numbers, track sizes and area names on the page. It is the quickest way to see why an item landed in the wrong cell.

## Common mistakes

- **Setting `display: grid` on the items** instead of the container.
- **A typo in an area name**, so the item falls into the next free cell instead.
- **Non-rectangular template areas**, which make the browser ignore the whole template.
- **Changing the visual order** with grid placement so it no longer matches the HTML order, which confuses keyboard and screen reader users.
- **Fixed pixel columns everywhere** (`300px 300px 300px`), which overflow on phones; use `fr` and `minmax()`.

## Quick recap

- `display: grid` plus `grid-template-columns` (and rows) define tracks; `gap` spaces them.
- `fr` shares the remaining space; `repeat()` saves typing.
- `grid-template-areas` draws a page layout; items join with `grid-area`.
- `repeat(auto-fit, minmax(150px, 1fr))` gives a gallery that adapts with no media queries.

## Try it

Open the **Do** tab and build a header, sidebar, main and footer page layout with template areas, plus a self-adjusting gallery.


Build a full page layout and a responsive gallery with CSS Grid, template areas and the fr unit.

Grid layout

Learn CSS Grid the easy way

Learn CSS Grid - A 13 Minute Deep Dive

## Why this matters

More than half of all web traffic comes from phones, and people also browse on tablets, laptops, ultra-wide monitors and TVs. A **responsive** page adapts to whatever screen it lands on instead of shipping a separate mobile site. Employers expect every front-end developer to build this way by default.

You already have two responsive tools: `flex-wrap` and `repeat(auto-fit, minmax())` adapt without any breakpoints. This lesson adds the rest: the viewport tag, fluid images and media queries.

## Step 0: the viewport meta tag

Without this line, phones pretend to be about 980px wide and shrink the whole page down until it is unreadable:

```html
<meta name="viewport" content="width=device-width, initial-scale=1">
```

It tells the phone to use its real width. Media queries will not behave as expected on phones without it. Do not add `maximum-scale=1` or `user-scalable=no`: blocking zoom is an accessibility failure.

## Fluid images

A 1,200px image inside a 360px phone screen overflows sideways. One rule fixes every image:

```css
img {
  max-width: 100%;   /* never wider than its container */
  height: auto;      /* keep the aspect ratio */
}
```

## Media queries

A media query applies CSS only when a condition is true:

```css
@media (min-width: 48em) {
  .layout {
    grid-template-columns: 2fr 1fr;
  }
}
```

- `min-width: 48em` means "when the viewport is at least 48em wide". In media queries, `1em` is the browser's default font size, usually 16px, so 48em is 768px. Using `em` makes breakpoints respond sensibly when users enlarge their default text.
- Rules inside the query are ordinary CSS rules. They follow the normal cascade, so a query placed **after** the base rule overrides it when it matches.
- Other useful features: `max-width`, `orientation: landscape`, `prefers-color-scheme: dark`, `prefers-reduced-motion: reduce` and `hover: hover`.

## Mobile-first versus desktop-first

**Desktop-first** writes the wide layout as the default and undoes it for small screens with `max-width` queries. **Mobile-first** writes the simplest, single-column layout as the default and *adds* complexity for larger screens with `min-width` queries:

```css
/* Base: phones and everything else */
.layout {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}
.nav-list {
  display: flex;
  flex-direction: column;
}

/* Tablets and up */
@media (min-width: 48em) {
  .layout { grid-template-columns: 2fr 1fr; }
  .nav-list { flex-direction: row; }
}

/* Large screens */
@media (min-width: 75em) {
  .layout { grid-template-columns: 3fr 1fr; }
}
```

Why most teams prefer mobile-first:

- The base CSS is the simplest version, so the smallest, often slowest devices get the least work.
- You add rules as space allows, rather than writing a layout and then overriding it.
- It forces you to decide what really matters on the page, because the phone layout has room for only the essentials.

## Choosing breakpoints

Do not pick breakpoints from a list of popular phone sizes; devices change every year. Instead, start narrow, widen the browser slowly, and add a breakpoint **where your content starts to look wrong**: lines grow too long, a sidebar has room to appear, the nav fits on one row. Most small sites need only one or two breakpoints.

## Worked example: testing responsiveness

1. Open developer tools and turn on **device mode** (the phone-and-tablet icon, or Ctrl+Shift+M / Cmd+Shift+M).
2. Choose a phone size such as 375px wide, then drag the width handle slowly up to 1,400px.
3. Watch the layout switch at your breakpoint. In Chrome, the **Media queries** bar above the page shows each breakpoint; click one to jump to that width.
4. Also test zoom: press Ctrl/Cmd and + to 200%. With `em` breakpoints, the layout should switch to the phone version, which is exactly what a low-vision user needs.
5. Finally, open the page on a real phone. Emulators are good, but touch targets and real fonts can surprise you.

## Common mistakes

- **Forgetting the viewport meta tag**, so phones show a tiny desktop page.
- **Mixing min-width and max-width queries** for the same components, which creates gaps and overlaps at the boundaries.
- **Putting the base rule after the media query**, so the base silently overrides the query.
- **Fixed widths** such as `width: 960px` on containers; use `max-width`.
- **Hiding important content on mobile** instead of rearranging it.

## Quick recap

- Add `<meta name="viewport" content="width=device-width, initial-scale=1">` to every page.
- `img { max-width: 100%; height: auto; }` makes images fluid.
- Mobile-first: single-column base styles, then `@media (min-width: ...)` adds layout as space grows.
- Pick breakpoints from your content, in `em`; test with device mode and zoom.

## Try it

Open the **Do** tab and convert a desktop-first recipe page to mobile-first.


Make a layout adapt from phone to desktop with the viewport meta tag, fluid images and min-width media queries.

Media queries and mobile-first

Learn CSS Media Query In 7 Minutes

Tutorial: Learn how to use CSS Media Queries in less than 5 minutes

Put your homepage in one folder with the home page named index.html, and change any image or stylesheet paths to relative, lowercase paths.

Read through every file (including HTML comments) and remove personal details you do not want public, such as a home address, phone number or any password.

Sign in to GitHub (create a free account if needed), turn on two-factor authentication, and create a new public repository.

Upload your files with Add file > Upload files (or git push) and commit them to the main branch.

In Settings > Pages, choose Deploy from a branch, select main and / (root), save, and wait for the site URL to appear.

Open the live URL. In developer tools, check the Network tab: every file should return 200, with no 404s.

Run the live URL through validator.w3.org and Lighthouse (Accessibility), and fix anything they report.

Open the site on a real phone and check that the layout switches to a single column and the text is readable without zooming.

## Why this matters

A site on your laptop is practice; a site with a public URL is a portfolio piece. Hiring managers for front-end, UI and design roles want links they can click, and a live homepage is the first link most beginners can show. It also completes the journey from the first lesson: now *your* files are on a server, answering *other people's* HTTP requests.

The good news: a static site (HTML, CSS, images and optional JavaScript, with no server code) can be hosted free, with HTTPS, and without a credit card.

## Your options

| Host | How you publish | Good for |
|---|---|---|
| **GitHub Pages** | push files to a GitHub repository | portfolio sites, project pages; your code is visible too |
| **Netlify** or **Cloudflare Pages** | drag and drop a folder, or connect a Git repository | quick deploys, previews of each change |
| **Codeberg Pages** and others | similar Git-based publishing | alternatives to GitHub |

All of them have free tiers for small static sites. This lesson uses GitHub Pages, because a GitHub profile is useful in its own right for developer jobs, and you will use Git and GitHub throughout your career (see the Git & the Command Line course). Free tiers and their limits change, so read the current terms on each provider's own site before you rely on one. Checked on 2026-10-23.

## Prepare your files

1. Put your site in one folder. The home page **must** be named `index.html`; web servers serve that file when someone visits the folder's URL.
2. Use **relative** paths for your own files: `href="styles.css"`, `src="images/me.jpg"`. Paths like `C:\Users\sam\Desktop\me.jpg` only work on your machine.
3. File names on most servers are **case-sensitive**: `Me.JPG` and `me.jpg` are different files. Lowercase names with hyphens (`about-me.html`) avoid surprises.
4. Remove anything private: your home address, phone number, unfinished notes in comments and any password or key. Everything you publish, including your HTML comments and file history in a public repository, can be read by anyone.

## Publish with GitHub Pages

1. Create a free GitHub account if you do not have one, and turn on two-factor authentication in your account settings.
2. Create a new **public** repository, for example `homepage`.
3. Upload your files: on the repository page choose **Add file > Upload files**, drag in `index.html`, your CSS and your images, and commit. (If you know Git, `git push` works too.)
4. Go to **Settings > Pages**. Under **Build and deployment**, choose **Deploy from a branch**, select the `main` branch and the `/ (root)` folder, and save.
5. Wait a minute or two. The Pages settings show your URL, usually `https://<username>.github.io/homepage/`. A repository named exactly `<username>.github.io` is served at `https://<username>.github.io/` instead.

Every time you commit a change to `main`, the site rebuilds automatically. GitHub's own documentation at docs.github.com/pages has the current screens and limits.

## Check it like a professional

Publishing is not the end. Run through this checklist on the **live** URL:

- **Validate:** paste the URL into validator.w3.org and fix any errors.
- **Accessibility:** run Lighthouse (Accessibility category) or the WAVE checker, then do a keyboard-only pass with Tab.
- **Responsive:** open the URL on a real phone and in device mode at several widths; zoom to 200%.
- **Network:** open the Network tab and reload. Every file should return `200`; a `404` means a wrong or case-mismatched path.
- **Share preview:** your `<title>` and a `<meta name="description" content="...">` are what appear in search results and many link previews.

## Custom domains (optional)

You can point a domain you own, such as `samrivera.dev`, at GitHub Pages or Netlify. Domains cost money every year, and you set them up with DNS records at your domain registrar (the DNS from the first lesson). A free `github.io` address is perfectly fine for a first portfolio.

## Taking it down

To unpublish, return to **Settings > Pages** and unpublish the site, or delete the repository. Remember that copies may survive in search caches for a while, which is one more reason never to publish anything private.

## Common mistakes

- **No `index.html`**, or a home page called `Index.html` or `home.html`, so the URL shows a 404.
- **Absolute paths to your own computer** and **case mismatches**, which cause broken images and missing CSS.
- **Publishing secrets or personal details** in a public repository.
- **Never checking the live site** after publishing.

## Quick recap

- Static sites host free with HTTPS on GitHub Pages, Netlify, Cloudflare Pages and similar services.
- Name the home page `index.html`, use relative lowercase paths, and remove private details.
- On GitHub: public repository, upload files, Settings > Pages > deploy from `main`.
- Validate, test accessibility, test on a phone and check the Network tab on the live URL.

## Try it

Open the **Do** tab and publish your homepage, then add the live link to your profile or CV.


Put your homepage on the public web for free with GitHub Pages, and check it like a professional.

Publish your site

How to host a website for free with GitHub pages

How to Deploy a Static Website to GitHub Pages - Free Hosting Tutorial

CSS Grid page layouts, mobile-first media queries, and publishing your site for free.