4 ms·

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

• spiderfarmer 9mo ago
  > 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 9mo ago
  The article explains how to style radio buttons with CSS however you want. What’s the problem with that?
  • supermatt 9mo ago
    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.
    • ifh-hn 9mo ago
      But is that still less complex than what the author found?
    • ruszki 9mo ago
      Can you give an example please? What kind of complexity are we talking about?
      • supermatt 9mo ago
        Any kind of nested markup: styled content, additional animation layers, etc.
        • paulhebert 9mo ago
          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
    • mcintyre1994 9mo ago
      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 https://codepen.io/mcintyre94/pen/pvbPVrP
      • supermatt 9mo ago
        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 9mo ago
      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.
• barryvan 9mo ago
  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 9mo ago
    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.
• archerx 9mo ago
  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.
  • christophilus 9mo ago
    The date picker still sucks.
    • archerx 9mo ago
      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.
      • charrondev 9mo ago
        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.
    • dlisboa 9mo ago
      Not on mobile. Most internet access these days is mobile.
  • dbbk 9mo ago
    And even select is fully customisable now if you're targeting modern browsers
    • efilife 9mo ago