Walk through how a browser turns an incoming stream of HTML bytes into a DOM tree, and explain why it does not wait for the whole document to arrive first.

## Stage 0: bytes to characters The network delivers bytes. Before anything can be tokenized the browser must know the encoding, which it takes from the `Content-Type` response header, a byte order mark, or a `<meta charset>` in the first part of the document. If it guesses wrong and then finds a `charset` declaration later, it may have to restart the parse — which is the practical reason `<meta charset="utf-8">` belongs in the very first bytes of `<head>`. ## Stage 1: tokenization The tokenizer is a state machine. It walks the character stream and, depending on its current state, emits tokens: - doctype - start tag (with its attributes) - end tag - character (text) - comment - end-of-file Seeing `<` moves it into tag-open state; a letter after that moves it into tag-name state; `>` emits the token and returns to data state. The state machine is why context matters so much: inside `<script>` or `<style>` the tokenizer switches to a raw-text state where `<div>` is just characters, not a tag. That is the mechanism behind the classic hazard of an unescaped `</script>` inside a string in an inline script — it ends the element, because the tokenizer is not parsing JavaScript, it is scanning for that sequence. ## Stage 2: tree construction Tokens are handed to the tree construction stage, which is where the DOM appears. It keeps a stack of open elements and operates in an *insertion mode* — "before head", "in head", "in body", "in table", and so on — and each mode has rules for each token type. This stage is far more than a bracket matcher. It: - **Inserts implied elements.** A document with no `<html>`, `<head>` or `<body>` tag still gets all three. A `<tr>` written directly inside `<table>` gets a `<tbody>` created around it, which is why the DOM you inspect rarely matches the HTML you wrote for tables. - **Closes unclosed elements.** A `<li>` still open when the next `<li>` starts is implicitly closed. - **Relocates stray content.** Text or elements that are not allowed inside `<table>` are moved out before it — the "foster parenting" rule — so the node ends up as a previous sibling of the table rather than inside it. - **Reconstructs active formatting elements**, which is how overlapping tags such as `<b><i></b></i>` are repaired into a valid tree. ## No fatal errors Unlike XML, HTML parsing never aborts. Every possible byte sequence has a defined outcome, and browsers agree on it because the recovery rules are specified, not invented per vendor. That is a feature — the web is full of broken markup and a blank page for a stray tag would be unacceptable — but it means a browser silently building a tree you did not intend is a normal failure mode. When a component renders in the wrong place, comparing the source with the DOM inspector is the first diagnostic. ## Why it is incremental The parser is fed each chunk of the response as it arrives; it does not buffer the document. Everything downstream inherits that property: nodes appear in the DOM, style can be computed for them, and the browser can lay out and paint what it has. A user can see and interact with the top of a long page while the server is still generating the bottom. Two consequences follow directly. **Streaming server responses pay off.** If a server flushes the head and the top of the page immediately and streams the rest, the browser can start fetching subresources and painting during the time the server spends assembling slow content. Buffering the whole response until it is complete throws that overlap away. **The DOM you observe mid-parse is provisional.** A script that runs during parsing sees only the nodes above it. Querying for an element that appears later in the document returns `null` — not because the selector is wrong, but because the node does not exist yet. This is the mechanical reason initialisation code either sits at the end of the document or waits for parsing to complete. ```js // In a script placed in <head>, before the element exists in the document: document.querySelector('#app'); // null — the parser has not reached it ``` ## What to say in an interview Name the two stages and use the right words — tokenizer and tree construction — then make the incremental point, because that is what the rest of the loading story hangs on: a streaming parser is what lets the browser overlap network, parsing and painting instead of doing them in sequence.