Form-associated custom element behavior issues

[pshaughn]

Most of the WPT custom-elements/form-associated tests fail for lack of ElementInternals. The few that don't look questionable by https://wpt.fyi/results/custom-elements/form-associated?label=master&label=experimental&aligned ; Servo's failures are consistent with Firefox and Safari's.

[jdm]

https://html.spec.whatwg.org/multipage/custom-elements.html#elementinternals

[pshaughn]

I'm going to map out how big the necessary changes are for this. It seems like the real-world use case of form-associated elements depends on shadow DOM somewhat, but the code needed to implement their semantics probably doesn't have any dependence on the code for shadow DOM.

[pshaughn]

I see no inherent semantic connection to shadow DOM at all. ElementInternals is an essential piece, however, since it's the main API by which an element's form value is accessed. The spec defines the value as conceptually existing on the element itself, separately from having attached internals, but the API about the value lives almost entirely in ElementInternals.

Here's what seems to be required, based on some spec-reading and my current understanding of Servo.

• CustomElementDefinition needs a couple more fields.
• A couple methods that iterate HTMLFormElement.controls need another case for seeing an HTMLElement that's custom and form associated; these include resetting the form and constructing the entry list of form data, among others.
• HTMLElements that happen to be form-associated custom elements need to "have" many values, probably too many to put directly into the HTMLElement struct. I am not sure whether these values are ever observable as anything but default-valued when no ElementInternals is attached. If they aren't, then maybe they should really live there, and the element should just have a dom reference to the attached internals. If they are, then maybe they should be in their own struct owned by HTMLElement via optional reference.
• ElementInternals needs to exist and have a few methods working.
• Upgrading an element needs to check if it's being upgraded to form-associated, and if so perform "reset the form owner" steps for it (which should end up with it being in the form owner's .controls).
• A few callback reactions need to get called at appropriate points when things happen to a form-associated CE.

None of this seems especially hard, and if ElementInternals and the other aspects are taken as a single unit, I don't think that unit depends on any other functionality Servo is missing. Deciding where to actually store the new form-associated values is an architectural decision that might have performance consequences.

There seems to be one confusing pitfall in the spec language, and anyone working on this should be alerted to it: when "the form owner" of an element "is reset", this is AFAICT a completely different concept from "reset the form owner" steps. The former is when the form is reset in the form-UI sense, and the latter is when the element becomes a child of an HTMLFormElement.