-
Notifications
You must be signed in to change notification settings - Fork 31
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
ElementInternals does not contain form if denoted by form attribute #89
Comments
Good callout. Looks like this works generally for all APIs as well. I'll have to poke around at the best way to solve this unless you'd like to take a shot at it. |
I added a workaround to our internal DS, if |
Yeah, my concern is basically wanting to confirm how this works if the form attribute changes midstream and how any values or behavior pivot. |
Yeah, here's an example of what I was worried about. Although it might be as simple as forwarding the test attribute to the hidden input … but there are likely other side effects to worry about like event listeners, etc. I'll play with it, but it won't be a fast fix. |
Thats alright; I think my naive workaround is enough for the foreseeable future. Let me know if theres anything I can do for you ^^. |
I just ran into this issue. I have a form which is submitted by a button which doesn't reside inside the form. |
The problem is more how to tell when the form changes. It would be feasible for a developer to do something along the following lines: html`
<form action="one" id="one">
<button type="submit">Continue</button>
</form>
<form action="two" id="two">
<button type="submit">Continue</button>
</form>
<x-control form=${someVariable ? 'one' | 'two'}></x-control>
`; When the value of I am taking some time off from writing code over the holiday season as I am recharging before starting my next role in January but I might get bored and try to take this on later. If someone else would like to claim it, let me know. |
I was reading the spec for form associated elements and it seems to not be that complicated. Basically, when the from attribute changes or the id of any element in the tree changes (I imagine document or shadow dom where the element is), then we have to recompute the form the element belongs too. So, we could follow the spec. It would require extending what the mutation observer is observing, and it is not that simple, but it is doable. If you guys agree, I could try making a PR to solve this issue, following the approach listed in the spec. |
Buttons can associate to forms that they are a descendant of, or forms that have an id specified by the
form
attribute.So can form associated custom buttons in Chrome (107), see for example this sandbox: https://codesandbox.io/s/loving-lena-p56owk?file=/index.html . Both the button inside the form, as well as the one specified by the
form
attribute can find the form it is associated to. (printed to the console on click).However, in browsers that require this polyfill, such as Safari, only the form associated button that is a descendant of the form can properly find its form.
The text was updated successfully, but these errors were encountered: