Don't run FACE reset algorithm in "create an element for token"

[domfarolino]

Fixes #10927. No browser implements "create an element for a token" > Step 13 fully. The reset algorithm is invoked, but NOT for form-associated custom elements, as tests indicate. This commit tightens the conditions under which we invoke the reset algorithm, to exclude form-associated custom elements, to match what browsers do.

• At least two implementers are interested (and none opposed): No browsers run the form-associated custom element reset algorithm in this scenario.
• Tests are written and can be reviewed and commented upon at: See https://github.com/web-platform-tests/wpt/blob/ab57bca30a4845855ea43fb318a9802beac8508f/custom-elements/form-associated/form-reset-callback.html#L52. This assert should cover what we want: that FACE reset algorithms are not run during "create an element for a token". See Reset algorithm doesn't work in form-associated custom elements #10927 (comment) too, and browser results here: https://wpt.fyi/results/custom-elements/form-associated/form-reset-callback.html?label=master&label=experimental&aligned.
• Implementation bugs are filed: N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: Doesn't seem necessary.
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/parsing.html ( diff )

[annevk]

This does stray a bit from the original goal of explaining behavior of form controls. It doesn't seem that useful per se, but I wonder if we want to at least briefly discuss this in a meeting to make the decision a bit more shared and intentional.

[domfarolino]

Sure. I added agenda+.

[annevk]

cc @whatwg/components

[domenic]

I tend to agree it's disappointing that nobody implemented this, and it would have been nice if they implemented it. I'm not sure it's worth the compat risk at this point though, so if we decide to go this direction, I'm OK with it.

[domenic]

Editorially LGTM