Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Should light DOM form controls in a form-associated custom element be ignored during form reset? #10290

Closed
kleinfreund opened this issue Apr 20, 2024 · 3 comments
Closed

Should light DOM form controls in a form-associated custom element be ignored during form reset? #10290

kleinfreund opened this issue Apr 20, 2024 · 3 comments
Labels
topic: custom elements Relates to custom elements (as defined in DOM and HTML)

Comments

@kleinfreund
Copy link

What is the issue with the HTML Standard?

TL;DR: Form controls inside a form-associated custom element are ignored on form submit. Should they also be ignored on form reset?

In the following document, two form controls are part of a form-associated custom element. Both controls' value is being set to "Bob". The second control is disassociated with the custom element's form by setting its form attribute to a non-existing/different form. That's done to illustrate the behavior I expected on form reset.

Pressing "Reset" will go through the usual motions of resetting the individual controls as per their reset algorithm. It'll also trigger the custom element's formResetCallback.

I think that's inconsistent with how such form controls are otherwise (i.e. on form submit) ignored. Is this the expected behavior?

The spec has only this to say about the reset algorithm of custom elements:

The reset algorithm for form-associated custom elements is to enqueue a custom element callback reaction with the element, callback name "formResetCallback", and an empty argument list.

demo.html:

<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="utf-8" />
	<meta name="viewport" content="width=device-width,initial-scale=1.0" />

	<title>test</title>
</head>

<body>
	<form>
		<custom-form-input name="custom-form-input" value="Alice"></custom-form-input>

		<button type="reset">Reset</button>
	</form>

	<script>
		class CustomFormInput extends HTMLElement {
			static formAssociated = true

			static {
				if (window.customElements.get('custom-form-input') === undefined) {
					window.customElements.define('custom-form-input', CustomFormInput)
				}
			}

			connectedCallback() {
				this.insertAdjacentHTML('beforeend', `
					<label>Name <input type="text"></label>

					<label>Name (with form="_") <input type="text" form="_"></label>
				`)

				this.querySelectorAll('input').forEach((el) => el.value = 'Bob')
			}
		}
	</script>
</body>

</html>

(It should be noted that this is only true if these form controls are in the light DOM.)

The practical consequence of this is that one has to do more work (e.g. disassociate form controls manually with form="non-existent-form") than to implement the desired reset behavior in formResetCallback which could look something like this:

formResetCallback() {
  this.#dirty = false
  this.#setValue(this.getAttribute('value') ?? '')
}
@annevk annevk added the topic: custom elements Relates to custom elements (as defined in DOM and HTML) label Apr 22, 2024
@annevk
Copy link
Member

annevk commented Apr 22, 2024

Aren't they only ignored for submission because they don't have a name attribute? It's also not really clear how these new controls relate to the custom element control. It seems like the custom element control is only used as a vehicle to insert them?

This seems more like a Stack Overflow question than an actual issue with the specification.

@kleinfreund
Copy link
Author

Aren't they only ignored for submission because they don't have a name attribute?

You’re right! Additionally, form reset behaves such that form controls with and without name attribute are reset. That is to say that form reset doesn’t distinguish between such controls and therefore, neither should form controls that are part of a form-associated custom element.

It's also not really clear how these new controls relate to the custom element control. It seems like the custom element control is only used as a vehicle to insert them?

That’s a byproduct of my attempt to cut down my demonstration to a minimum. In the context where I started wondering about this, it was a color picker composed of a handful of inputs (e.g. three inputs for RGB) with a form value being something like rgb(1 2 3 / 0.5). The individual input’s reset behavior was interfering with how I wanted it to work. It doesn’t make much sense to keep several value attributes on these individual controls when you already have <color picker value="rgb(0 0 0 / 0.5)"></color-picker>, but I digress.

This seems more like a Stack Overflow question than an actual issue with the specification.

That’s a fair assessment. I wasn’t sure exactly how to categorize my ask and didn’t realize it was a misunderstanding of how form controls contribute values on form submit (and really rather unrelated to form-associated custom elements in particular). Knowing that, I don’t consider this an issue with the spec anymore and will close this issue.

@kleinfreund kleinfreund closed this as not planned Won't fix, can't repro, duplicate, stale Apr 22, 2024
@annevk
Copy link
Member

annevk commented Apr 22, 2024

To be clear, creating a minimum viable example is great and very helpful. I recommend trying to go even further next time as that would have yielded <form><input value=Bob><input type=reset><input type=submit></form> and might have made it immediately apparent what was going wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: custom elements Relates to custom elements (as defined in DOM and HTML)
Milestone
No milestone
Development

No branches or pull requests
2 participants
@annevk @kleinfreund