selectedcontent issues

[untitaker]

There are a few issues with the selectedcontent implementation of html5ever:

• The implementation of "clone an option into selectedcontent" is wrong. It does not create a new documentfragment but reparents options onto the root of the current document. I'm not sure how that could've happened, I guess that since Relax <select> parser (WHATWG proposal) #560 was opened the spec has been iterated on.
• whatwg/html@4ce63af1 removes the </option> transition, and says that the algorithm for "maybe clone an option" needs to be run everytime any option is popped off the stack of open elements. html5ever is lagging behind here, and it seems that runnign something everytime the stack of open elements is truncated requires a larger refactor.

[untitaker]

I also think that these regressiontests should be added to html5lib-tests, not sure if that new behavior is covered there.

[simonwuelker]

I propose removing https://docs.rs/html5ever/latest/html5ever/interface/trait.TreeSink.html#tymethod.clone_subtree and instead adding https://html.spec.whatwg.org/#clone-an-option-into-a-selectedcontent as a TreeSink callback.

[simonwuelker]

I believe the way we track the enabled selectedcontent element of the nearest ancestor select is very wrong - we set the variable here:

html5ever/html5ever/src/tree_builder/mod.rs

Lines 1408 to 1412 in b4194ce

	if qname.local == local_name!("selectedcontent")
	&& self.selectedcontent_elem.borrow().is_none()
	{
	*self.selectedcontent_elem.borrow_mut() = Some(elem.clone());
	}

and this is the only place where it is mutated. A couple of things that we don't implement:

• The selectedcontent element is only relevant when its enabled, which we never check
• It must be the first selectedcontent in tree order of its <select> ancestor
• the <select> must not have a multiple attribute

and there's probably more. The relevant part of the specifcation is https://html.spec.whatwg.org/#select-enabled-selectedcontent.