Back to learning
Web development

HTML & Web Foundations

Build, debug, publish and explain a real web page — starting from never having written a line of code.

  • Beginner
  • About 5 weeks
  • 6 milestones
  • 20 steps
  • 10 reviewed
AccessibilityHTMLCSS
Start this journey
What you will have builtA published web page at a public address, built from a written requirement, that works on a phone and a laptop — and an explanation of its decisions an engineer who never saw it can follow.Start this journey

What this asks of you

Every figure below is read from the journey itself, not written about it.

BeginnerNo prior experience needed
About 5 weeksAn estimate, not a deadline
6 milestonesEach one claims a capability
20 stepsShort, and every one is built
10 reviewedAn engineer reads these, when mentor guided

What you will be able to do

Every milestone claims one engineering capability. You reach it by building something, not by finishing a chapter.

A page is a structured documentBuild a page whose structure reflects what the content means, and see it render in a browserBeginners arrive believing HTML makes text big. That belief quietly damages every stylesheet, every layout and every accessibility fix that follows.
3 steps
Show the 3 steps
  • Your first page exists

    Create an HTML file, open it in a browser, change it, and see your change.

  • Elements name what content is

    Structure supplied text by choosing elements for what the content is, not for how you want it to look.

  • Documents have shape

    Nest elements correctly, and read a page as a tree of containers rather than a list of lines.

Requirements become structureTurn a written brief into a defensible page structure, and explain the element choicesNobody hands an engineer structured content. They describe what is needed and expect you to work out the rest — and this is the first milestone where more than one answer is defensible.
3 steps
Show the 3 steps
  • From a description to a structureReviewed

    Read a written requirement and decide what structure it implies, before writing any markup.

  • When the requirement changesReviewed

    Adapt an existing structure to a changed requirement, and tell the difference between a change needing more of what you have and one needing a different shape.

  • Structure you cannot seeReviewed

    Make a page's meaning survive when it is not being looked at — by someone using a screen reader, or when images fail to load.

Appearance is a separate concernStyle a page to a described appearance, and predict what a rule will affect before applying itMost CSS confusion is a wrong mental model of what the browser already did, not a missing fact. Meeting the model early is what stops the next three milestones being guesswork.
4 steps
Show the 4 steps
  • Telling the browser which things you mean

    Write a CSS rule that changes exactly the elements you intended.

  • Everything is a box

    Control the space inside and around an element, and predict the size the browser will give it.

  • Why your rule did not apply

    Work out which rule the browser actually used when two could apply, and fix a rule that is not taking effect.

  • When the design changes

    Adapt a stylesheet to a changed appearance requirement, and tell which changes need new rules, which need new structure, and which need a capability you do not have yet.

Layout decisionsDecide whether normal flow already satisfies a layout requirement, choose and implement a Flexbox arrangement when it does not, and predict how it behaves when content or space changesThe first milestone that gives a requirement and no approach. Layout is where beginners lose weeks to guessing, and deciding the model once ends that.
3 steps
Show the 3 steps
  • Does this even need a layout system?

    Given a layout requirement, tell whether normal flow and spacing already satisfy it or whether it genuinely needs a layout system.

  • Making the browser arrange things

    Turn an element into a Flexbox container and control how its items sit along one axis.

  • What happens when things change

    Choose an arrangement for a layout requirement involving growth and varying screen size, implement it, and say what it does at widths you did not design for.

When the browser disagrees with youState the symptom precisely on an unfamiliar page, form hypotheses, use browser evidence to rule them in or out, correct the actual cause, and explain the reasoning that got thereDebugging is the most transferable skill in engineering and the one most reliably omitted, because authors write journeys in which everything works. A journey without it teaches only the happy path.
3 steps
Show the 3 steps
  • You already know how to do thisReviewed

    Work a fault through a stated diagnostic loop instead of changing things until it looks right.

  • Reading the evidenceReviewed

    Use the browser to find out what it actually did, and use the gap between that and what you wrote to locate a cause.

  • A fault you have never seenReviewed

    Diagnose the cause of faults in an unfamiliar page from evidence, without being told what kind of fault each one is, and explain how you got there.

Ship it and explain itPublish your own work to a public address and explain it to an engineer who did not build it — what you decided and why, what went wrong and how you found it, and what you would change if the requirements changedEverything so far was written for you, or for a mentor who has been reading along. Being unable to explain your own work is how good work goes unrecognised and unreviewed.
4 steps
Show the 4 steps
  • The briefReviewed

    Turn a written brief for your own project into a plan — content, structure and a layout approach — before writing anything.

  • Build itReviewed

    Build a working, structured, styled, responsive page on your own.

  • Put it on the internetReviewed

    Publish a static site to a public address and verify it works there rather than only on your machine.

  • Explain it to another engineerReviewed

    Explain your work to an engineer who did not build it, and answer questions about what you would do if the requirements changed.

How the work is verified

  1. ReadThe context you need for this step, and why it matters. Never more than that.
  2. BuildYou produce something real. The work is yours, in your own repository.
  3. SubmitYou send it, with a note on what you chose and what you were unsure about.
  4. ReviewA senior engineer reads it and responds. They may ask for changes — that is the normal path through engineering review, not a failure.
  5. VerifiedThe capability is confirmed, it goes on your record, and the next step opens.

How you want to work

You choose when you start. Both cover the same journey and the same definition of done.

Mentor guidedReviewed by a person

A senior engineer is assigned to you. They read every submission, respond in writing, and decide when a capability is verified. Expect to be asked for changes.

Self pacedVerified by you

You work through the same journey and verify your own work against the same definition of done. Nothing is submitted to anyone, and nothing waits on anyone.

What you end up with

Counted from this journey, not described in general.

A published web page at a public address, built from a written requirement, that works on a phone and a laptop — and an explanation of its decisions an engineer who never saw it can follow.Built by you, in your own repository.
10 pieces of work, each read by an engineerEvery round and every comment stays on the record, including what changed between them.
6 verified capabilitiesEach one confirmed against its definition of done, with the name of whoever confirmed it. There is no certificate. The work is the credential.

Ready to start HTML & Web Foundations?

You will choose how you want to work on the next screen. Nothing starts until you confirm it. You can run several journeys at once, and each one is mentor-guided or self-paced on its own.

Start this journey