This is the kind of stuff we have to do because almost all browser <input> elements are terrible in terms of customisability. Especially radios and selects

If you're one of those who think we should just use the default, bear in mind that the default radio button has poor usability for mobile users.

▲

barryvan 6 hours ago | parent | next [-]

There are lots of ways to style these native controls, though, including ways to start from scratch and retain the accessibility affordances.

I'd be curious to know more about the usability issues you've found on mobile -- I've not had any personally when using radio buttons. I'll readily grant you that 'select' is awful everywhere though!

	▲	DrewADesign 5 hours ago \| parent [-]
		It’s a lot easier now than it used to be. Radio buttons used to be nearly impossible to style, and I still think they require scripting to de-select— so none in a group are selected after one has been selected. I’ll bet most of the complexity in the article is some combination of keeping support for older browsers, technical debt, and nobody complaining about it because it works.

▲

spiderfarmer 6 hours ago | parent | prev | next [-]

> bear in mind that the default radio button has poor usability for mobile users

Wrap it in a label, give the label a padding. Boom!

▲

ruszki 6 hours ago | parent | prev | next [-]

The article explains how to style radio buttons with CSS however you want. What’s the problem with that?

▲

supermatt 6 hours ago | parent [-]

It doesn’t.

It gives a very naive approach that doesn’t support any complex styling.

For that you need to wrap the input and additional styling elements in a ref’ed label.

▲

mcintyre1994 5 hours ago | parent | next [-]

Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP

	▲	supermatt 2 hours ago \| parent [-]
		In the example they are just using an empty <RadioGroup.Indicator/> for the pip as it is easy to target with a classname, but you can put any content in there instead for e.g. card-style radios (as used for complex selections, like a subscription tier). By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector. The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).

▲

whstl 5 hours ago | parent | prev | next [-]

Wrapping it in a label is the idiomatic and correct way, and should be done even when not styling. Perhaps especially when not styling.

Putting an adjacent label is also possible, but scales poorly due to needing unique ids.

▲

ruszki 5 hours ago | parent | prev | next [-]

Can you give an example please? What kind of complexity are we talking about?

	▲	supermatt 2 hours ago \| parent [-]
		Any kind of nested markup: styled content, additional animation layers, etc.

▲

ifh-hn 5 hours ago | parent | prev [-]

But is that still less complex than what the author found?

▲

archerx 5 hours ago | parent | prev [-]

The only <input> that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.

▲

dbbk 38 minutes ago | parent | next [-]

And even select is fully customisable now if you're targeting modern browsers

	▲	efilife 10 minutes ago \| parent [-]
		really? how?

▲

christophilus 4 hours ago | parent | prev [-]

The date picker still sucks.

	▲	archerx 4 hours ago \| parent \| next [-]
		I admit I haven’t had to use the date picker in a long time but I looked at the MDN for an example of the default implementation of it and it seemed fine on my iPhone. What issues have you encountered with it? I imagine it’s a different story on desktop browsers.
	▲	dlisboa 3 hours ago \| parent \| prev [-]
		Not on mobile. Most internet access these days is mobile.