You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That is correct, if it's outside of a form, there isn't any need for any native component anyway because bubbling only makes sense within forms.
That is not correct. See a simplified example of my case:
<div><AbstractedCheckboxlabel="Accept terms and conditions"name="consented"form="terms-form"/><formid="terms-form"onSubmit={(event)=>console.log(Object.fromEntries(newFormData(event.target)))}/></div>// result -> {}// result when form wraps checkbox -> { consented: "on" }
Forms are not always the parent of form fields. In the above case, Radix doesn't realize it's part of a form, and so doesn't render an <input> element, and the checkbox state doesn't end up in the FormData.
Expected behavior
An <input>/native element is rendered when the form attribute is present.
Suggested solution
This line in Checkbox.tsx (and in Switch and elsewhere)...
Or... just always render an <input>? Not sure why it was decided to avoid it, every other library, headless or not, seems to always render an <input> and just visually and accessibly hide it as appropriate.
Additional context
This is a perfectly valid feature of the HTML spec...
... so I don't like having to justify why I would need it, but here is some context.
I tend to do it this because that way the form does not affect layout or styling. Yes I'm aware of display: contents but that does not prevent it from completely changing the CSS selectors required. As such, I tend to have an abstract form component that gets portaled to the body.
I'm sure there are many other cases why someone might need the input element there.
Workaround
As a very unpleasant workaround, to my <AbstractCheckbox> component I've had to track and sync a local copy of the checked state and add an invisible (visually and accessibly) <input> so the form can pick it up, like this (irrelevant stuff removed):
I'm planning to address this shortly. We'll need a more wholistic solution for all affected components, and I want to do some manual testing to ensure this doesn't impact click interactions for elements outside of its associated form.
Bug report
Current Behavior
In #874, @benoitgrelard says...
That is not correct. See a simplified example of my case:
Forms are not always the parent of form fields. In the above case, Radix doesn't realize it's part of a form, and so doesn't render an
<input>
element, and the checkbox state doesn't end up in theFormData
.Expected behavior
An
<input>
/native element is rendered when theform
attribute is present.Suggested solution
This line in
Checkbox.tsx
(and in Switch and elsewhere)...should be changed to something like...
Or... just always render an
<input>
? Not sure why it was decided to avoid it, every other library, headless or not, seems to always render an<input>
and just visually and accessibly hide it as appropriate.Additional context
This is a perfectly valid feature of the HTML spec...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#form
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fae-form
... so I don't like having to justify why I would need it, but here is some context.
I tend to do it this because that way the form does not affect layout or styling. Yes I'm aware of
display: contents
but that does not prevent it from completely changing the CSS selectors required. As such, I tend to have an abstract form component that gets portaled to the body.I'm sure there are many other cases why someone might need the input element there.
Workaround
As a very unpleasant workaround, to my
<AbstractCheckbox>
component I've had to track and sync a local copy of the checked state and add an invisible (visually and accessibly)<input>
so the form can pick it up, like this (irrelevant stuff removed):The text was updated successfully, but these errors were encountered: