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.

Sign up for GitHub

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

Jump to bottom

[Radio] Allow to be used standalone without RadioGroup #1328

Open
nizhnyk opened this issue Jan 13, 2025 · 6 comments
Open

[Radio] Allow to be used standalone without RadioGroup #1328

nizhnyk opened this issue Jan 13, 2025 · 6 comments
Assignees
@atomiks
Labels
component: radio This is the name of the generic UI component, not the React module!

Comments

@nizhnyk
Copy link

nizhnyk commented Jan 13, 2025

Feature request

Summary

Enhance the Radio component to support standalone usage without requiring it to be part of a RadioGroup. Specifically, add support for checked and onChange props. This will allow developers to manage the state of individual Radio components, enabling more flexibility for custom visual designs or use cases where RadioGroup is not needed.

Examples in other libraries

Motivation

The current implementation tightly couples the Radio component with RadioGroup, making it less versatile in scenarios where developers:

  1. Need a static representation of radio buttons for read-only or decorative purposes.
  2. Want to use the Radio component for custom designs without needing full RadioGroup functionality.
  3. Handle state or interactions independently for each Radio, such as in the case of custom forms, polls, or conditional UI.

By allowing Radio to accept checked and onChange, developers can use it more flexibly in a variety of contexts. Currently, developers building their own components on Base UI need to create two versions of Radio components: one based on the Base UI Radio for use with RadioGroup, and another that is a clone of the first to be used independently without RadioGroup. Supporting checked and onChange directly in the Base UI Radio would eliminate the need for such duplication, simplifying development and improving consistency across implementations.
@github-actions github-actions bot added the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Jan 13, 2025
@github-project-automation github-project-automation bot moved this to Backlog in Base UI Jan 13, 2025
@zannager zannager added the component: radio This is the name of the generic UI component, not the React module! label Jan 13, 2025
@onehanddev
Copy link
Contributor

Hi @colmtuite, If possible, I would love to pick this up, Can you please assign it to me ?

@colmtuite
Copy link
Contributor

I've added this to backlog for now. Radio items are not valid outside of a radio group, so in order to add support for it, I will need some more information on why you'd ever want to do that.

Need a static representation of radio buttons for read-only or decorative purposes.

Are you talking about a radio item card or something? Where there is a purely decorative radio button type visual artefact inside the card? If so, this can be done by styling <div aria-hidden>, and just hiding the Indicator.

Want to use the Radio component for custom designs without needing full RadioGroup functionality.

I can't think of any design where a radio is needed outside of a group?

@nizhnyk
Copy link
Author

nizhnyk commented Jan 15, 2025

Radio items are not valid outside of a radio group

I may be wrong but I haven't found this explicitly listed in any HTML specification. Standard HTML radio input supports checked and onChange, they also don't need to be wrapped in anything, the radio group is defined by the name property.

Based on my own research, MDN Web Docs for example say: "<input> elements of type radio are generally used in radio groups" Which doesn't mean it's invalid when used standalone.

I have also created basic HTML structure with standalone Radio button and in a Radio Group, both pass HTML validation on https://validator.w3.org/#validate_by_input

Standalone:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Standalone Radio Button</title>
</head>
<body>
    <h1>Standalone Radio Button Example</h1>
    <input type="radio" id="radio1">
    <label for="radio1">Standalone Radio</label>
</body>
</html>

In Radio Group:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Grouped Radio Buttons</title>
</head>
<body>
    <h1>Grouped Radio Buttons Example</h1>
    <input type="radio" id="radio2" name="group">
    <label for="radio2">Option 1</label>
    <br>
    <input type="radio" id="radio3" name="group">
    <label for="radio3">Option 2</label>
</body>
</html>

I have already changed my code to use RadioGroup so I personally don't require this feature but it may benefit someone else, like those migrating from Material UI.

My specific use case was for polls and quizes that were built using Material UI 5 which supported standalone Radio buttons.
It's using standalone Radio buttons to display read-only poll and quiz results. I have now converted it to Radio Group but this wasn't necessary as it's just for decorative purposes.
Another use is when adding quizes and to mark which answer is correct. In this case it's used as radio group because there is same name prop assigned to Radio component, which Material UI supports. I had to do a bit of work and move functions and components around to wrap them in RadioGroup.

@elieven elieven marked this as a duplicate of #1344 Jan 19, 2025
@elieven
Copy link

elieven commented Jan 19, 2025

@colmtuite check my duplicate issue to see one more usage example. Basically more complex forms and inputs are where this is needed. Also just following the vanilla HTML/JS functionality would be good.

@atomiks atomiks self-assigned this Jan 20, 2025
@atomiks atomiks removed the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Jan 20, 2025
@atomiks
Copy link
Contributor

atomiks commented Jan 20, 2025

In order for this to properly work @elieven, where adding the name attribute on Radio.Root without a RadioGroup works, it needs to leverage the browser's native radio group focus management on the inputs. This means each input can't be hidden and needs to be involved in the styling. It looks like Ant makes it position: absolute and covers the whole parent span (in our case button), and Material UI is similar

It looks like Radix doesn't allow this behavior, though. In your case, what is the downside of wrapping RadioGroup around the entire table? The role="radiogroup" wrapper?

@colmtuite
Copy link
Contributor

I may be wrong but I haven't found this explicitly listed in any HTML specification.

@atomiks I meant from a UX perspective moreso than a spec perspective. Perhaps "valid" was the wrong word choice. What I'm wondering is, is there a reasonable requirement for supporting this, that justifies the documentation issues that will likely arise from it? I can't think of any reasonable use case for an isolated radio button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@atomiks atomiks

Labels
component: radio This is the name of the generic UI component, not the React module!
Projects
Base UI
Status: Backlog
Milestone
No milestone
Development

No branches or pull requests
6 participants
@colmtuite @onehanddev @nizhnyk @atomiks @elieven @zannager