Relax <select> parser (WHATWG proposal)

[untitaker]

Neither the proposal nor the test changes are merged yet.

html5lib/html5lib-tests#178
whatwg/html#10557

[nicoburns]

@untitaker I'm not sure if you still have time to work on this, but spec proposal has now been merged, and we'd love to get html5ever updated to match. There are conflicts here because we eliminated the proc macro from rules.rs (see #640), but this is a really just a mechanical/syntactical change that should be fairly easy to adapt to.

I also wanted to notify you that this crate has seen a revival in activity and maintainence in the last few months, and to invite you to collaborate with us if you are interested in doing so.

[untitaker]

i'm stumped on how to implement this part of the spec which seems to be part of handling </option> in in-body insertion mode: https://html.spec.whatwg.org/multipage/form-elements.html#maybe-clone-an-option-into-selectedcontent

to me this implies that the TreeSink trait needs methods for traversing the ancestors of the tree. Is that right? Then this is a breaking change.

[nicoburns]

to me this implies that the TreeSink trait needs methods for traversing the ancestors of the tree. Is that right?

I haven't looked into this deeply, but we already keep track of the currently open <form> element so that we can associate elements with it (https://github.com/servo/html5ever/blob/main/html5ever/src/tree_builder/mod.rs#L120). Could a similar approach be used for <select>?

...is a breaking change

If it is a breaking change then that's probably not a big deal: html5ever makes breaking changes quite frequently

[untitaker]

Progress update. Indeed the conflict resolution was trivial, but since I opened the PR, the corresponding spec PR has significantly expanded in scope. So it's not all easy.

• The recently added tests for <selectedcontent> contain this input:

  <select><button><selectedcontent></button><option>X
  

  And expect X to be duplicated into <selectedcontent>. However, according to the spec, the routine responsible for that ("maybe clone option...") is only called from within the transition for </option> end tags. so now I'm confused where that </option> token is coming from? it's not coming from the tokenizer, and from what i can tell nothing in the spec says the treebuilder has to fabricate it. is it dynamically inserted post-tree-building?

  EDIT: Popping node vs. end tag behavior in <option> and <selectedcontent> whatwg/html#11653

• the "selectedness" of a <option> element influences what gets cloned into <selectedcontent>. however, "selectedness" is not part of tree building. the selectedness attribute is set to true based on the selectedness algorithm. The only way I can see it being part of tree building is if we consider the selected attribute from the original input, but in the testcase there is none. The testcase just assumes we're doing way more than treebuilding.

Am I missing something?

filed html5lib/html5lib-tests#180

[untitaker]

in order to move forward with updating html5lib-tests i ignored the remaining two tests. they are testing full DOM behavior which html5ever does not care about.

[untitaker]

@nicoburns i think this can be reviewed/merged

[jdm]

This is great work. Thank you for doing it, and sorry for sitting on it for so long without feedback!

[simonwuelker]

I am currently running into issues when trying to bump servo to include this change, since reparent_children internally calls Node::Append and that throws an exception when the new parent is a document node.

Should the old children of the selected content really end up as children of the document? That seems odd.

[untitaker]

yeah I think that's broken, added an issue here #712