Skip to content

Potential regression in Radio component default tag behavior in v2 #3667

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

Open
GeorgeGkas opened this issue Mar 13, 2025 · 0 comments
Open

Potential regression in Radio component default tag behavior in v2 #3667

GeorgeGkas opened this issue Mar 13, 2025 · 0 comments

Comments

@GeorgeGkas
Copy link

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

2.2.0

What browser are you using?

This issue seems to be a regression introduced in v2 and occurs regardless of the browser version.

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 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

  1. 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.
  2. 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant