Regression with calcite-button#form where form is not submitted/reset

[nwhittaker]

Actual Behavior

Given a submit or reset button associated with a non-ancestor form, clicking the button does not submit/reset the form.

Expected Behavior

Given a submit or reset button associated with a non-ancestor form, clicking the button does submit/reset the form.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/wvmQjMO

Reproduction Steps

1. Visit the sample and enter some text into the input.
2. Click the reset button and not the input does not clear.
3. Open the console and click the submit button and note "onsubmit" is not printed.

Reproduction Version

beta.91

Relevant Info

Possibly introduced by #3287.

I'd also ask to revisit the decision to deprecate the form attribute. Marking it as deprecated suggests it'll be removed from the API at some point in the future. I understand it's no longer needed in the case where the buttons are descendants of the <form>, but if they're not, the attribute is still needed and perfectly valid.

Regression?

next.290

[jcfranco]

I understand it's no longer needed in the case where the buttons are descendants of the <form>, but if they're not, the attribute is still needed and perfectly valid.

Agreed. We can revisit our form-associated pattern to accommodate this. In the meantime, can you use the form-descendant approach as a workaround?

For prioritization, can you share more info about your use case and the impact of this?

[nwhittaker]

For prioritization, can you share more info about your use case and the impact of this?

One use-case where I came up against this issue was when I tried to treat the contents of a modal like a form, and the modal's buttons like form buttons:

<calcite-modal>
  <form id="form-id" onsubmit="…" slot="content">
    <calcite-input />
  </form>
  <calcite-button form="form-id" slot="primary" type="submit" />
  <calcite-button form="form-id" slot="secondary" type="reset" />
</calcite-modal>

This lets me consolidate the submission logic and retain native submission behavior:

• Click submit button
• Hit Enter key when input is focused

Currently achieving this behavior would require separate handlers and added logic:

<calcite-modal>
  <form slot="content">
    <calcite-input onkeyup="…" />
  </form>
  <calcite-button onclick="…" slot="primary" type="submit" />
  <calcite-button onclick="…" slot="secondary" type="reset" />
</calcite-modal>

You might run into this problem with other components that separate actions from content, but is perhaps more easily mitigated by just wrapping the whole thing inside a <form>. The modal doesn't have quite the same affordance because it could be wormholed out of its current spot in the DOM.

[geospatialem]

This issue will be prioritized after the 1.0 release next month.

[brettephillips]

Our team (Real-Time & Big Data: ArcGIS Velocity) is running into the same problem. We could use the workaround suggested by @nwhittaker, but this would be a large LOE and could cause some regression as there are a lot of moving parts. It is currently blocking a lot of our tests and verification

[geospatialem]

Assigned for researching next steps with the form utility.

[geospatialem]

Verified on master.