An HTML page's <head> contains a stray <div> before its <meta> and <link> tags. What does the parser do at that point, and what stops working?

## The head's content model `<head>` is not a free-form container. Its content model is metadata content, which in practice means exactly these elements: - `<base>` — the document base URL - `<link>` — stylesheets, icons, resource hints, canonical - `<meta>` — charset, viewport, named metadata - `<noscript>` — but only containing link/style/meta - `<script>` - `<style>` - `<template>` - `<title>` — required, and exactly one Comments and whitespace are allowed anywhere and do **not** end the head. Anything else does. ## What the parser does — no error, a recovery HTML parsing never fails. The tree-construction stage is a state machine, and while it is in the "in head" state, a start tag it does not recognise as head content is handled by an *implied end tag*: the parser behaves as though `</head>` appeared, moves on, and then — still holding the unrecognised token — opens `<body>` and reprocesses the token there. ```html <head> <meta charset="utf-8"> <title>Orders</title> <div class="wrapper"> <!-- head ends here, implicitly --> <meta name="description" content="..."> <!-- this is in <body> now --> <link rel="stylesheet" href="/app.css"> <!-- so is this --> </head> <!-- ignored: head is already closed --> <body> <!-- ignored: body is already open --> ``` The explicit `</head>` and `<body>` tags further down are simply dropped, because the parser has already moved past those states. Nothing in the console tells you this happened. ## What breaks, tag by tag This is where the answer gets interesting, because the consequences are uneven — which is precisely why the bug survives review. - **`<link rel="stylesheet">`** still works. Browsers honour stylesheet links found in the body, so the page renders styled and looks correct. It does change when styles arrive relative to content, which can surface as a restyle of content already painted above. - **`<script>`** still runs. No visible symptom at all. - **`<meta charset>`** is the real casualty. It is now both outside `<head>` and, in any realistic document, beyond the 1024-byte window the browser pre-scans for an encoding declaration. The browser has already committed to a guessed encoding, and non-ASCII text can render as mojibake. - **`<base>`** is meant to precede every element carrying a URL. After an implicit body start there is usually markup above it that has already resolved against the document URL, so resolution is split across two bases. - **Validators and tooling** flag the document, and any tool that reads metadata by looking at `document.head` — or by parsing the head server-side — will miss tags that are technically in the body. ## How this ships in real projects Almost never by someone typing a `<div>` into a head on purpose. The usual causes are a templating partial that emits a wrapper element, a layout that concatenates fragments in the wrong order, a stray character or unescaped text from a CMS field interpolated into the head, or a mis-nested conditional that closes a tag early. Server-side rendering makes it worse, because the head is assembled from several independently-owned partials. ## How to find and prevent it The fastest diagnosis is the DevTools Elements panel: expand `<head>` and see where it actually ends, versus what the source says. `document.head.children` in the console gives the same answer programmatically. Beyond that, run the markup through an HTML validator in CI, and treat the head as an owned, small, single-authored region of the template rather than a place partials append to freely. ## What an interviewer is checking Two things. First, that you know HTML parsing is *error-recovering by specification*, not error-reporting — invalid markup produces a defined, silent DOM rather than a failure. Second, that you can reason about a bug whose most visible symptoms are absent: the page looks right, the styles apply, and only the encoding and the metadata-consuming tools are wrong.