Popping node vs. end tag behavior in <option> and <selectedcontent>

[dmsnell]

What is the issue with the HTML Standard?

The recent changes in #10548 modify the parsing behavior so that a selected OPTION element will be appropriately cloned into the appropriate SELECTEDCONTENT. However, there seems to be a discrepancy between how the rules are written and how Chrome currently implements this.

(Given that this is currently a Chrome-only feature in production it’s unclear to me how other standards-compliant browsers and parsers will handle it).

The only reference to run the maybe clone an option into selectedcontent algorithm is found in the section for an end tag whose name is OPTION. However:

• Chrome clones the appropriate OPTION into a SELECTEDCONTENT even when no end tag whose name is OPTION appears.
• It is reasonable and preferable that the cloning operation runs regardless of the particular tokens in the markup.

Since the cloning probably needs to occur whenever popping any OPTION element off of the stack of open elements, it needs to run both during generate implied end tags and also when performing any pop operation on the stack of open elements.

[josepharhar]

I agree that this is a missing part of the spec, we should do that in generate implied end tags.

It also makes me wonder if any other end tag rules for other elements are missing in generate implied end tags, and if the fix should be more generic to run end tag rules for any tag that gets closed in generate implied end tags.

[annevk]

cc @whatwg/html-parser

[dmsnell]

@josepharhar note that it’s not only in generate implied end tags where we might expect the algorithm to run. If I’m not misreading the spec, when:

• IN BODY we encounter a star tag whose name is SELECT.
• The parser was not created as part of the fragment case with SELECT as context element.
• The stack of elements has a SELECT element in scope.

Then we:

Pop elements from the stack of open elements until a select element has been popped from the stack.

So I think that this step skips generating implied end tags but might implicitly close any open OPTION elements, none of which contain the expected end tag, and one of which might be the selected content.

<select id="real">
<option>a
<option selected>b
<select id="closes-real-but-is-ignored">

[zcorpan]

Handling in generate implied end tags is still not sufficient, because, at least, the end-of-file token doesn't run those steps.

There are a couple of "When a foo element is popped off the stack of open elements of an HTML parser or XML parser," phrasings:

https://html.spec.whatwg.org/#:~:text=The%20element%20is%20popped%20off%20the%20stack%20of%20open%20elements%20of%20an%20HTML%20parser%20or%20XML%20parser%2E

https://html.spec.whatwg.org/#:~:text=the%20element%20is%20popped%20off%20the%20stack%20of%20open%20elements%20of%20an%20HTML%20parser%20or%20XML%20parser%2C

https://html.spec.whatwg.org/#:~:text=true%2E-,When%20a%20media,false

https://html.spec.whatwg.org/#:~:text=When%20a%20textarea%20element%20is%20popped%20off%20the%20stack%20of%20open%20elements%20of%20an%20HTML%20parser%20or%20XML%20parser%2C%20then%20the%20user%20agent%20must%20invoke%20the%20element%27s%20reset%20algorithm%2E

I think that ought to work for option as well.

[annevk]

We should have a follow-up issue on formalizing all those better though, I think. We don't want COMEFROM.