Rename <formControl>.form to associatedForm

[andreasunger]

Currently, form controls have an optional form property to set the ID of the associated form. Native form controls also have a read-only form property for accessing the actual associated form element.

The API mismatch between Web Awesome's custom form controls and the native ones makes it more difficult to write generic code that can handle both (getForm for WA controls, form for native controls).

To fix the mismatch, I propose renaming the form property to something like associatedForm and make the form property a read-only getter for getting the form element (what getForm currently does).

[KonnorRogers]

🤔 I thought I had changed this.

input.form -> HTMLFormElement // => behaves like the browser
input.form = "my-form" -> <wa-input form="my-form">
set form (str) {this._form = str} would reflect to an attribute, the browser no-ops when you set a form to a string on native elements and just ignores it.

slightly different from the platform, but slightly more convenient to be able to set the form with a string, and tends to play nicer with frameworks that only understand properties and not attributes. Dont know how other feels about the "polymorphic" API, but I think I may have walked it back for fear of it being confusing 🤔

@LeaVerou / @claviska would love your thoughts on making it a getter / setter like above.

But I do agree .form should return the HTMLFormElement.

[claviska]

At a glance, the proposed API does seem confusing but OP raises a good point in that, if our form controls follow the platform's patterns, it will be easier to make them work with form-related utilities.

[KonnorRogers]

@claviska i dont expect many people to use it that way, but I dont know if things like React special handle properties like "form" on form controls like <input> which are attribute only.

Its more like a compatibility shim than it is for use by a user.

[claviska]

Admittedly, one problem I've run into with custom elements in general is that form utilities usually look at the tag name and rarely provide an opt-in for custom elements, so that might be a reason not to care about alignment in this case. 🤔

[andreasunger]

Is there a concern with just renaming the property to something other than form? If the concern is that the name associated-form is too close to form, there may be other options like associated-with, owned-by, part-of, contained-in, child-of, ... .

Using the property to get the associated HTMLFormElement (e.g., to validate an input value against other form controls) is probably more common than using it to associate the control with a form that is not a parent.

[KonnorRogers]

@andreasunger Personally, I think el.form should return the HTMLFormElement. I think where @claviska and I are hung up on is if you should be able to assign a form with the same API, or should need to do something like:

el.formId = 'my-form'

Polymorphic APIS where you have a getter that returns an HTMLFormElement, and a setter that only accepts a string feels...weird.

get form (): HTMLFormElement
set form(val: string): void

my question is more so "should form be settable via property"

EDIT:

the platform currently only accepts a form "attribute" but does not accept a form "property"

<form id='my-form'></form>

<input>

<script>
  const input = document.querySelector("input")
  input.form // => null
  input.form = "my-form" // => does nothing
  input.form // => null

  input.setAttribute("form", "my-form") // properly associates with the HTMLFormElement.
  input.form //=> HTMLFormElement
</script>