Clarification needed: `select` fragment parsing with `<input><option>`

[EmilStenstrom]

In the correctness benchmark, there is one remaining difference between Lexbor/selectolax and JustHTML for this html5lib tree-construction case:

tests_innerHTML_1.dat
#data
<input><option>
#document-fragment
select
#document
| <input>
| <option>

JustHTML currently matches the html5lib fixture and produces:

| <input>
| <option>

Lexbor/selectolax currently produces:

| <option>

I checked the current WHATWG HTML Living Standard, including the newer customizable select / selectedcontent changes, and it looks like Lexbor’s behavior may be correct for the latest spec.

The relevant current parser rule says that for a start tag whose tag name is input, if the parser was created as part of the HTML fragment parsing algorithm and the context element is a select element, this is a parse error and the token should be ignored:

https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody

The fragment parsing algorithm also resets the parser’s insertion mode based on the context element:

https://html.spec.whatwg.org/multipage/parsing.html#html-fragment-parsing-algorithm

So for this fragment:

<input><option>

with context element:

<select>

I would expect the input token to be ignored and the resulting tree to be:

| <option>

That differs from the current html5lib test fixture, which expects:

| <input>
| <option>

Could someone clarify whether this html5lib test is now outdated relative to the current WHATWG spec, or whether there is another rule that still makes the fixture expectation correct?

[annevk]

#195