10.2 — The HTML Parser, Interlocking & Fault Tolerance

Streaming Parsing – Building the DOM in Chunks

Unlike a traditional compiler that expects a complete file in memory, the HTML parser begins work the moment the first network packet arrives. Raw bytes flow into the tokenizer while the server is still sending data. The parser processes a chunk, builds part of the DOM tree, then pauses if it runs out of input – resuming exactly where it left off when the next packet arrives.

This incremental architecture dramatically reduces the time to first paint, but it also means the tokenizer and tree constructor must be capable of operating on incomplete document fragments at any moment.

The Style‑Script Interlock

When the HTML parser encounters a synchronous <script>, it must stop. But if the script appears after a stylesheet, an even stricter rule kicks in: the script cannot execute until all pending CSS is fully downloaded and the CSS Object Model (CSSOM) is built.

Why? JavaScript can query an element’s computed styles. If the stylesheet hadn’t been applied, the script would receive stale or non‑existent data – a catastrophic race condition. The browser enforces a strict dependency chain:

• Parser is blocked by <script>.
• <script> execution is blocked by pending CSS.
• The main thread remains suspended until the CSSOM is ready, guaranteeing deterministic behaviour for the script.

Error Recovery – The Adoption Agency Algorithm

Mis‑nested inline formatting tags (e.g., <b>...<i>...</b>...</i>) are one of the most common authoring mistakes. A naive parser would create a tangled, invalid DOM. The HTML tree constructor uses the adoption agency algorithm to repair this seamlessly.

The algorithm maintains a list of active formatting elements. When it detects an overlap, it unwinds the stack of open elements, isolates the mis‑nested tags, clones the necessary formatting nodes, and re‑parents the text beneath them. The result is a perfectly valid, well‑nested tree – and the visual rendering remains correct.

Error Recovery – Foster Parenting

A second extreme case is when text or block elements are placed directly inside a <table> but outside any <td> or <th>. A strict XML parser would reject this outright. The HTML parser uses foster parenting: it searches backward through the stack of open elements, finds the table’s context, and moves the stray node before the table in the DOM.

This ensures the visual table layout remains intact, while the illegal content is still preserved and rendered – it is never discarded. The web’s supreme directive is never to break existing content, and foster parenting is one of the mechanisms that upholds that promise.