Build a web browser engine

Split the URL into scheme, host, port and path. Open a TCP socket, wrap it in TLS for https, and write the request yourself: a request line, a Host header, and a blank line. Read the status line and headers, then the body.

Getting the body right is the first real lesson. With keep-alive the server won't close the connection, so you have to stop at Content-Length bytes or decode chunked transfer encoding. Add redirects while you're here; a lot of the web answers with a 301 first.

Throw the tags away for now: keep only the text between them, and decode the common entities like & and <. Draw it word by word, measuring each word with the font, and wrap when the next one won't fit.

Then add scrolling by moving everything up and skipping words that are off screen. It's crude, but it's a browser. Every milestone from here replaces one piece of this with the real thing.

Write a tokenizer that emits start tags with attributes, end tags, text and comments. Then a tree builder that keeps a stack of open elements. Handle void elements like br and img, which never get an end tag.

Real HTML is full of mistakes, and the spec says exactly how to repair them. A p isn't closed before the next p, so the parser has to close it for you. Implement the handful of implied end tags and implicit html, head and body elements, and most pages will come out right.

Parse stylesheets into rules: a list of selectors and a list of declarations. Start with tag, class, ID and descendant selectors. Match them against each element, and when several set the same property, the most specific one wins, with source order breaking ties.

Then handle inheritance: properties like color and font-size pass down to children unless something overrides them. You'll also want a small user-agent stylesheet of your own, the defaults that make h1 big and p a block with margins.

Build a layout tree from the styled DOM. For a block box, the width comes from the parent's content width minus margins, borders and padding; the children are laid out top to bottom; and the height is the sum of theirs. That top-down, bottom-up pass is the heart of CSS layout.

Test it against a real browser. Make a page of coloured, nested boxes, open it in both, and compare. Matt Brubeck's "Let's build a browser engine" covers this milestone particularly clearly.

Text isn't laid out as boxes stacked vertically. It flows into line boxes: each word is placed after the last, a new line starts when the next word won't fit, and every word on the line is aligned on a shared baseline using the font's ascent and descent.

Mixed content is where it gets tricky. When a block holds both text and block-level children, you need anonymous block boxes to wrap the loose text. Expect this milestone to take a bit longer than you planned.

Walk the layout tree and emit a display list: rectangles for backgrounds and borders, text runs at positions. Drawing is now a loop over that list, and scrolling only changes an offset, so you don't re-run layout on every key press.

For clicks, do hit testing: find the deepest layout box under the pointer, walk up to its a element, and resolve its href against the page URL. Relative URLs, ../ segments and scheme-relative links all have rules. Keep a history stack and you have a browser you could actually use for simple sites.

Don't write the language. Embed an existing engine such as QuickJS or Duktape, run each script tag, and expose a small DOM API to it: querySelector, addEventListener, innerHTML and textContent.

The interesting part is the other direction. A script can change the DOM at any point, so your browser has to mark what's stale and redo style, layout and paint before the next frame. This is where keeping the stages separate pays for itself.