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
We are updating @headlessui/react in one of our projects from v1 to v2. After running multiple visual tests, we have identified a potential regression regarding the Radio component, which is not mentioned in the official upgrade guide. It seems that the default tag for RadioGroup.Option component is set to div in v1 radio-group.tsx#380 whereas in v2 the same component which was renamed to Radio defines span as default tag radio-group.tsx#468.
Given the fact that the library Deprecated RadioGroup.Option component
We've deprecated the RadioGroup.Option in favor of the more terse Radio component.
we would expect the behavior to be consistent. If this is the intended behavior, we totally understand. However, it does break HTML semantics, since div is a block element and span is an inline element. This difference also affects styling, as not all styles apply equally to block and inline elements. I've attached two reproducible examples above so you can see the behavior in action, simply inspect the HTML tag of the Radio element in the preview to verify.
Mitigation strategies
In our case, we'll simply add as="div" to the Radio element to render it as a <div>, matching the default behavior of RadioGroup.Option.
Potential actions
If this is not the intended behavior, we should consider creating a fix that sets the default tag of the Radio element to div, aligning it with RadioGroup.Option. However, applying this change could potentially break projects that have already migrated to v2 and adjusted their codebases to accommodate the new behavior.
It may also be worth updating the "Default element changes" section in the v2 release changelog to mention Radio. Alternatively, a note could be added under the "Deprecated RadioGroup.Option component" section to clarify this change.
I'm not sure if this issue has been reported before (I couldn't find anything related on the GitHub Issues page), nor did I see it mentioned in any upgrade guides, but wanted to bring this to your attention. Let me know your input regarding this. I believe we need to communicate it somehow to our user base.
Lastly, a big shoutout to @tomaszczubakTW for bringing this regression to my attention and sparking this investigation!
The text was updated successfully, but these errors were encountered:
What package within Headless UI are you using?
What version of that package are you using?
What browser are you using?
Reproduction URL
Describe your issue
Hello headlessui team,
We are updating
@headlessui/react
in one of our projects from v1 to v2. After running multiple visual tests, we have identified a potential regression regarding theRadio
component, which is not mentioned in the official upgrade guide. It seems that the default tag forRadioGroup.Option
component is set todiv
in v1 radio-group.tsx#380 whereas in v2 the same component which was renamed toRadio
definesspan
as default tag radio-group.tsx#468.Given the fact that the library
Deprecated RadioGroup.Option component
we would expect the behavior to be consistent. If this is the intended behavior, we totally understand. However, it does break HTML semantics, since div is a block element and span is an inline element. This difference also affects styling, as not all styles apply equally to block and inline elements. I've attached two reproducible examples above so you can see the behavior in action, simply inspect the HTML tag of the Radio element in the preview to verify.
Mitigation strategies
In our case, we'll simply add
as="div"
to the Radio element to render it as a<div>
, matching the default behavior ofRadioGroup.Option
.Potential actions
Radio
element todiv
, aligning it withRadioGroup.Option
. However, applying this change could potentially break projects that have already migrated to v2 and adjusted their codebases to accommodate the new behavior.I'm not sure if this issue has been reported before (I couldn't find anything related on the GitHub Issues page), nor did I see it mentioned in any upgrade guides, but wanted to bring this to your attention. Let me know your input regarding this. I believe we need to communicate it somehow to our user base.
Lastly, a big shoutout to @tomaszczubakTW for bringing this regression to my attention and sparking this investigation!
The text was updated successfully, but these errors were encountered: