Repository navigation
Popping node vs. end tag behavior in <option> and <selectedcontent> #11653
Description
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
OPTIONappears. - 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.
Activity
josepharhar commentedon Sep 11, 2025
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 commentedon Sep 12, 2025
cc @whatwg/html-parser
dmsnell commentedon Sep 12, 2025
@josepharhar note that it’s not only in
generate implied end tagswhere we might expect the algorithm to run. If I’m not misreading the spec, when:SELECT.SELECTas context element.SELECTelement in scope.Then we:
So I think that this step skips generating implied end tags but might implicitly close any open
OPTIONelements, none of which contain the expected end tag, and one of which might be the selected content.zcorpan commentedon Sep 16, 2025
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
optionas well.annevk commentedon Sep 16, 2025
We should have a follow-up issue on formalizing all those better though, I think. We don't want COMEFROM.
josepharhar commentedon Oct 7, 2025
Thanks @zcorpan! I will make a paragraph like that for option elements for now.
I agree. Would it make sense to move them all into one algorithm that runs any time any element is popped off the stack of open elements? I suppose that it's not perfect unless we also instrument every place that pops elements off the stack of open elements.
Does this have an explicit step which pops elements off the stack which we could instrument?
Improve behavior for parsing option end tags
josepharhar commentedon Oct 7, 2025
I made a PR here: #11764
annevk commentedon Oct 8, 2025
Presumably this is what WebKit (and I guess Chromium) call
finishParsingChildren()? It seems reasonable to let elements define such steps and then the parser pops we run those steps for the relevant element, if it has any defined. (Or they have them always defined but by default no-op.)Generally the existence of this mechanism is a bit of a design smell and cannot be replicated by custom elements as it would make it very easy to design elements that work declaratively, but not imperatively. I'm not sure how to convey that properly however.
Right, I think we want to make "popping" an algorithm.
Yeah I think so. "Stops parsing" and "abort a parser" both pop.
add selectedcontent element
implement selectedcontent element logic
Improve behavior for parsing option end tags
annevk commentedon Oct 14, 2025
Follow-up issue: #11781.
Improve behavior for parsing option end tags
add selectedcontent element
implement selectedcontent element logic