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

@annevk Thanks. My comment before was more for posterity's sake for people searching for a workaround. I haven't fully delved what I'd like to see a proposal consist of. Right now I have my own code in my FACE `InputMixin`:

````js
   /**
     * @see https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission
     * @param {Event} event
     * @return {void}
     */
    performImplicitSubmission(event) {
      const form = this.form;
      if (!form) return;
      /** @type {HTMLInputElement} */
      let defaultButton;
      const submissionBlockers = new Set();
      for (const element of /** @type {HTMLCollectionOf<HTMLInputElement>} */ (form.elements)) {
        // Spec doesn't specify disabled, but browsers do skip them.
        if (element.type === 'submit' && !element.disabled && !element.matches(':disabled')) {
          defaultButton ??= element;
          break;
        }

        if (IMPLICIT_SUBMISSION_BLOCKING_TYPES.has(element.type)) {
          submissionBlockers.add(element);
        }
      }
      if (defaultButton) {
        defaultButton.click();
        return;
      }
      if (submissionBlockers.size > 1) return;
      this.form.submit();
    }
````

This is to handle if users press 'Enter' on a FACE element, like `<x-checkbox>` or `<x-text-input>`. The spec asks to fire a click event on the button. This seems like enough to satisfy *that* requirement. (side-note: `:disabled` isn't ready on Safari yet.)

The question would really be, would a FACE listed in `form.elements` with `[type="submit"]` be satisfactory? Right now it's a Submit-Like button because I don't bother to check if it's an `HTMLButtonElement` or `HTMLInputElement`. 

The other question is, why wouldn't it be enough for any FACE button that has `.type === 'submit'` to just be considered a submit button. Would that not be enough without requiring extra (and possibly redundant) JS code? Are there situations where `type` is not `submit` and it can be a submit button? Are there situations where `type` *is* `submit` and it is not a submit button?

Another point, form.requestSubmit spec says:

>form.[requestSubmit](https://html.spec.whatwg.org/multipage/forms.html#dom-form-requestsubmit)([ submitter ])
Requests to submit the form. Unlike [submit()](https://html.spec.whatwg.org/multipage/forms.html#dom-form-submit), this method includes [interactive constraint validation](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#interactively-validate-the-constraints) and firing a [submit](https://html.spec.whatwg.org/multipage/indices.html#event-submit) event, either of which can cancel submission.

>The submitter argument can be used to point to a specific [submit button](https://html.spec.whatwg.org/multipage/forms.html#concept-submit-button), whose [formaction](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formaction), [formenctype](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formenctype), [formmethod](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formmethod), [formnovalidate](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formnovalidate), and [formtarget](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-formtarget) attributes can impact submission. Additionally, the submitter will be included when [constructing the entry list](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constructing-the-form-data-set) for submission; normally, buttons are excluded.

With IDL showing:

>undefined [requestSubmit](https://html.spec.whatwg.org/multipage/forms.html#dom-form-requestsubmit)(optional [HTMLElement](https://html.spec.whatwg.org/multipage/dom.html#htmlelement)? submitter = null);

My interpretation that the submitter in requestSubmit *can* be a submit button, but does not need to be and it maybe a browser error to check against HTMLInputElement or HTMLButtonElement. Chrome should not be firing:

>Uncaught TypeError: Failed to execute 'requestSubmit' on 'HTMLFormElement': The specified element is not a submit button.
at HTMLButtonElement.

Nothing in the steps say to perform this check. It may be a necessary step to build some Web Platform Tests to target this "mistake". 

I'm of the opinion that

* FACE authors should opt-in to perform implicit submission with their own code. Perhaps a <form> may include a shortcut *later* called `form.performImplicitSubmission()`, but that's out of scope for now. (If it's automatic, opt-out would be `preventDefault()` on `Enter` keydown, though that would probably break compatibility with current FACE.)
* Any FACE with `.type === 'submit'` is a submit button
* Browsers should not perform instance/type checks on the element passed to `form.requestSubmit(submitter)`.

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

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