Is the initial submission value of a form-associated custom element really supposed to be null?

[pshaughn]

WPT test custom-elements/form-associated/ElementInternals-setFormValue.html "Null value should submit nothing" contrasts two controls: one for which setFormValue has explicitly been called on its ElementInternals with an argument of null, and one for which internals are attached but setFormValue has never been called.

It expects the form to submit a query string that excludes the explicitly nulled element entirely, but includes the unset one as though it has an empty-string value. If the initial submission value is really null, as https://html.spec.whatwg.org/multipage/custom-elements.html#face-submission-value says, then the two elements should have the same behavior as each other.

Chrome/Edge pass the test, meaning their initial submission value behavior differs from spec; as Firefox and Safari aren't implementing it at all yet, this seems to raise a question as to whether the spec is saying the right thing.

Here's a link to the test case; the value setter on the custom element class is what calls setFormValue, and the constructor of the custom element attaches internals but does not call setFormValue.
https://github.com/web-platform-tests/wpt/blob/4f09d6508beb51df94feeb09c431549fdb26a201/custom-elements/form-associated/ElementInternals-setFormValue.html#L84-L95

[annevk]

cc @whatwg/forms

[tkent-google]

I think it's an implementation bug of Chrome, and a test bug. I filed crbug.com/1051292.
Probably I changed my mind about the initial value when I wrote the specification, and forgot to change the implementation and the test.

[tkent-google]

Fixed by web-platform-tests/wpt#21747