Item — HN Reader

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.

4 comments

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!

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.

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

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.

The date picker still sucks.

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.

It’s been good on mobile for a while, and it’s a travesty on desktop.

Then if you want something a little bit complicated you have to do it all yourself.

- What if I need a date range instead of a single date? - What if I have excluded dates? (Only weekdays/only in the future/blackout dates) - What if I want to show other metadata with each day? (Like in a calendar showing each day with some metadata next to it)

Beyond “give a whatever the system thinks is a good date picker that I have no control over” the input with type date isn’t very useful.

Not on mobile. Most internet access these days is mobile.

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

really? how?

The article says browser support is limited, but good docs: https://developer.mozilla.org/en-US/docs/Learn_web_developme...

Appearance: base-select

https://developer.chrome.com/blog/a-customizable-select

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

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.

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

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

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.

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

Any kind of nested markup: styled content, additional animation layers, etc.

Author here. Can you provide a screenshot or more detail?

I'd be happy to implement an HTML + CSS only solution and share it with you.

Thanks

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