Two issues with recent changes to select parsing

[untitaker]

I'm trying to update html5ever to conform with recent changes to tree building done in #178, and hit two issues:

• webkit02 contains tests that require option content to be cloned into <selectedcontent> even if no </option> tag appears in the markup. However, the spec currently implies that an explicit markup tag </option> is required for <selectedcontent> to be filled out. this is tracked as a spec issue -- I would suggest that html5lib-tests in the meantime aligns with the spec rather than chromium/webkit.

• The tree construction tests assume that the selectedness of an <option> has been determined. but if I understand correctly that means constraint validation for forms has been running, which seems fairly out of scope for those tests.

[gsnedders]

@josepharhar — can you take a look?

[josepharhar]

webkit02 contains tests that require option content to be cloned into <selectedcontent> even if no </option> tag appears in the markup. However, the spec currently implies that an explicit markup tag </option> is required for <selectedcontent> to be filled out. this is tracked as a spec issue -- I would suggest that html5lib-tests in the meantime aligns with the spec rather than chromium/webkit.

I will work on this spec issue. I'm not opposed to changing the tests in the meantime before that is done.

The tree construction tests assume that the selectedness of an <option> has been determined. but if I understand correctly that means constraint validation for forms has been running, which seems fairly out of scope for those tests.

Which test is testing selectedness? Is this about selectedcontent or something else?

[untitaker]

Basically it's not clear to me which option (out of many) is supposed to be cloned into selected content during tree construction. I can see the argument that during parsing, we pick the one with a selected attribute, but the spec says to rely on selectedness which seems to be determined after tree construction generally.

The tests only ever contain one option, but selectedness is not determined for that single option either (and it has no selected attribute)

[josepharhar]

When option elements are inserted, including during tree construction, selectedness is determined by the selectedness setting algorithm: https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element:~:text=index%20is%20zero.-,The%20option%20HTML%20element%20insertion%20steps,-%2C%20given%20insertedOption%2C%20are

Basically, if any option has the selected attribute, then the last option with the selected attribute is selected and cloned. If no options have the selected attribute, then its the first option.

[untitaker]

I see, thank you. I'm coming at this from a place of implementing parsing libraries, and to my knowledge it's very uncommon to have complete DOM implementation in those. See this test PR, which also fails html5ever as insertion mode for <detail> is actually not implemented there at all: #181

so I guess there is no spec issue but really just a question about what the scope of this testsuite is supposed to be.

[sideshowbarker]

Might be good to also hear @hsivonen’s thoughts on this, if he has time to chime in

[annevk]

Couple of thoughts here:

1. This test suite really ought to be integrated into web-platform-tests directly. Not being able to contribute to it directly as part of web browser development is a major hurdle.
2. It seems reasonable for tests that depend on a particular HTML element class implementation to be separable in some way. We could either put them in a separate file or have web browser / generic expectations. (I suspect this also applies to script execution for instance.)

[untitaker]

Regarding point 1, i think the best way would be to have a "test name" we can use in harnesses to ignore the test. right now html5ever ignores tests by filename + offset