HTML API: Update parsing for customizable select elements

[jonsurrell]

The HTML standard is being updated to support customizable select elements. The HTML API should be updated to account for the new changes.

​WHATWG/HTML PR 10548 had landed with the updates. Several browsers already have support and MDN pages have been updated for ​select, ​selectedcontent, and a new ​guide on customizable select elements.

There's also an ​html5-lib tests PR that updates tests to account for the changes.

Trac ticket: #63736

The HTML standard is being updated to support customizable select elements. The HTML API should be updated to account for the new changes.

​WHATWG/HTML PR 10548 had landed with the updates. Several browsers already have support and MDN pages have been updated for ​select, ​selectedcontent, and a new ​guide on customizable select elements.

There's also an ​html5-lib tests PR that updates tests to account for the changes.

Update HTML API parsing to account for changes in ​https://github.com/whatwg/html/pull/10548.

Apply ​https://github.com/html5lib/html5lib-tests/pull/178.

Todo:

• [ ] Update the html5lib-tests README and sha when the PR lands.

​This can be tested with the HTML API Debugger.

The HTML5-lib test updates were merged: ​https://github.com/html5lib/html5lib-tests/pull/178

My reading on this is that when we close an OPTION element we check if we are the first element with selected and that the parent SELECT is not a multiple.

If that’s the case we should be able to infer that we are inside a SELECTEDCONTENT and fib it, should we want to. This is something we could possibly track through a boolean flag in the parser.

Interesting the spec reads like this cloning _only_ occurs when encountering an end tag whose name is OPTION. That’s not what Chrome is doing, because it clones the element when there are no closing tags. It’s like they are doing it upon the event of closing the OPTION instead of encountering the end tag.