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.

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

Cannot specify form= attribute on form element #1742

Closed
Conduitry opened this issue Sep 15, 2018 · 6 comments · Fixed by #2670
Closed

Cannot specify form= attribute on form element #1742

Conduitry opened this issue Sep 15, 2018 · 6 comments · Fixed by #2670
Labels
awaiting submitter needs a reproduction, or clarification bug

Comments

@Conduitry
Copy link
Member

Specifying the form= attribute on form element results in code that attempts to set the .form property on the element, which throws an error as that is read-only.

I'm not sure what the desired behavior here is. The immediately obvious path is to just not treat form= specially on form elements, and just generate setAttribute calls for this. But I don't know whether that's going to do the same thing as having a form= attribute on an element in regular old HTML.

@Conduitry Conduitry added bug help wanted awaiting submitter needs a reproduction, or clarification labels Sep 15, 2018
@Conduitry Conduitry reopened this Mar 7, 2019
@ankitsinghaniyaz
Copy link

Can someone please explain this in more detail with a reproduction? I'm willing to look into this and help fix.

@Conduitry
Copy link
Member Author

Huh. When I created this issue, I was getting an exception from the browser when attempting to update the .name property of a form. I'm not getting that now though, in latest Firefox or Chrome. I don't know whether something changed and browsers support this now, or whether something else happened.

A component like this:

<script>
	let foo = 'foo';
</script>

<form name={foo}></form>
<input bind:value={foo}>

produces output that the browser seems to be completely happy with. I'm not sure what's going on or whether this is still an issue.

@Conduitry
Copy link
Member Author

Oops. Completely disregard that last comment. I misread my own issue somehow. Hold on...

@Conduitry
Copy link
Member Author

Okay, here's what's really going on:

The issue arises when compiling a component that has something like <input form='foo'> - This results in code that attempts to set the (read-only) property .form on the form element. We could probably avoid the exception by setting the form attribute on the DOM element instead, but I don't know whether that would have the desired effect. I don't know whether the associated form for an input element is something that you can programmatically update, or how to manually specify it when creating the DOM nodes from in js.

@ankitsinghaniyaz
Copy link

ankitsinghaniyaz commented Apr 23, 2019

The id of the <form> of which the input is a member; if absent, the input is a member of the nearest containing form, or is not a member of a form at all

This is what I got from MDN and I understand what the form attribute here means and that can be set by the developer writing the code.

@Conduitry I see you using two terms Form Element and DOM Element and you also say that the .form is read-only on the form element. What do you exactly refer to as the form element?

I guess updating the form attribute programmatically is possible. Here is how I tested it.

image

@MikeMatrix
Copy link
Contributor

While digging into this issue, as noticed by @Conduitry , it seems that form is a read only property on all of the considered elements.
Also notably svelte defines some elements to contain form that are absent from documentation and behavior in my tests.
Namely keygen, meter, and progress which are defined to use this key here:
https://github.com/sveltejs/svelte/blob/master/src/compile/render-dom/wrappers/Element/Attribute.ts#L311-L325

Also doing some testing with weather or not the same behavior can be achieved using setAttribute, it seems like it works just fine with this method.
Some hastily put together test code: https://codesandbox.io/s/v6moy5npk3

So I guess the solution is likely to just remove the form property from attribute_lookup so the attribute would fall through and get applied with attr?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting submitter needs a reproduction, or clarification bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants