Re: [WICG/webcomponents] Form-associated custom elements: being a submit button (#814)

@annevk Forgive my ignorance. I see now what you mean about invoking JS to get a state/property. I was thinking about how the disabled state works. In my use case I bind `[disabled]` to `XElement.prototype.boolean` so I had improperly assumed it was the JS element that was at work here.

The reality is `[disabled]` (the attribute) is tracked:

>The element is a [button](https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element), [input](https://html.spec.whatwg.org/multipage/input.html#the-input-element), [select](https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element), [textarea](https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element), or [form-associated custom element](https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-element), and the [disabled](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-disabled) attribute is specified on this element (regardless of its value).

Along the same vein a `[type=submit]` check could allow a FACE to be form-associated submit button. It sounds like you can avoid JS that way. Though, I'm not sure how useful in practice it really is.

>As for implicit submission, if the only FACE you have is a submit button, I think you'd want implicit submission from a non-FACE to do something with it.

The steps for implicit submission should cover it, IMO. Once the browser finds the submit button, FACE or native, it should perform a `click()` action.

>It's a good question what should happen inside a FACE with regards to implicit submission. I guess that cannot deviate from what happens today, though perhaps we should create an affordance for that as well?

At first I was worried about authors who have built combo-boxes that expect `ENTER` to do something (eg: select from a dropdown list) and would inadvertently find themselves having their forms being submitted in an incompletely state because they now would have to ensure `.preventDefault()` was called.  But on second thought, how would an author who is manually performing implicit submission steps (see my code above) know that a FACE is a submit button? I'm checking `form.elements` for `(element.type === 'button')`. But since `XButton.prototype.type` isn't mandatory, and neither is `<x-button type="submit">` we either need a way to either allow authors to script their own implicit submission, or provide a function to invoke. 

Example: 

````html
<x-checkbox>Vendor-1 Checkbox</x-checkbox>
<y-submit-button>Vendor-2 Submit button</y-submit-button>
````

If FACE `XCheckbox` wants to perform implicit submission, the steps I had of iterating (form.elements) is not sufficient because FACE Submit does not expose itself as submit button in any normalized way, even if `YSubmitButton._elementInternals.submitButton === true` . One solution is to require `[type=submit]`. Another would be a function that `XCheckbox` can invoke where the browser can perform all the implicit submission steps (eg: `this._elementInternals.performImplicitSubmission()`).

Side note: I did now notice that we don't have the ability to block implicit submission from FACE elements. Now that I understand `[type]` isn't tracked with FACE, but only with `<input>`, we don't have a way for FACE to satify:

>[...] an element is a field that blocks implicit submission of a [form](https://html.spec.whatwg.org/multipage/forms.html#the-form-element) element if it is an [input](https://html.spec.whatwg.org/multipage/input.html#the-input-element) element whose [form owner](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-owner) is that [form](https://html.spec.whatwg.org/multipage/forms.html#the-form-element) element and whose [type](https://html.spec.whatwg.org/multipage/input.html#attr-input-type) attribute is in one of the following states: [Text](https://html.spec.whatwg.org/multipage/input.html#text-(type=text)-state-and-search-state-(type=search)), [Search](https://html.spec.whatwg.org/multipage/input.html#text-(type=text)-state-and-search-state-(type=search)), [URL](https://html.spec.whatwg.org/multipage/input.html#url-state-(type=url)), [Telephone](https://html.spec.whatwg.org/multipage/input.html#telephone-state-(type=tel)), [Email](https://html.spec.whatwg.org/multipage/input.html#email-state-(type=email)), [Password](https://html.spec.whatwg.org/multipage/input.html#password-state-(type=password)), [Date](https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)), [Month](https://html.spec.whatwg.org/multipage/input.html#month-state-(type=month)), [Week](https://html.spec.whatwg.org/multipage/input.html#week-state-(type=week)), [Time](https://html.spec.whatwg.org/multipage/input.html#time-state-(type=time)), [Local Date and Time](https://html.spec.whatwg.org/multipage/input.html#local-date-and-time-state-(type=datetime-local)), [Number](https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number))

That means we also need `this._elementInternals.blocksImplicitSubmit === true`. I don't personally the concept of having a `[type]` attribute that is referred against a list. Something set internally just seems cleaner.

---- 

Summed up:

1. `this.#elementInternals.submitButton === true;`
2. `this.#elementInternals.implicitSubmit();`
3. `this.#elementInternals.blocksImplicitSubmit === true;`

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/814#issuecomment-1429788941
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/814/1429788941@github.com>