Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I normally share the sentiments of the article. But I am also curious, if the goal was:

- Implement the radio as the designer sent in the figma file (e.g. something like the radix demo one they're commenting on: https://www.radix-ui.com/primitives/docs/components/radio-gr...)

- Make sure it looks the exact same across all browsers

How doable is it with vanilla css? The example they gave was rendered to a black/white circle, most teams wouldn't ship that.



You can get a lot closer with only small modifications:

    input[type="radio"] {
      appearance: none;
      margin: 0;
      width: 25px;
      height: 25px;
      background: white;
      border-radius: 50%;
      display: inline-grid;
      place-content: center;
      box-shadow: 0 2px 10px color(display-p3 0 0 0/0.5);

      &::before {
        content: "";
        width: 11px;
        height: 11px;
        border-radius: 50%;
      }

      &:checked::before {
        background: color(display-p3 0.383 0.317 0.702);
      }
    }
Here's a link to a codepen so you can see what it looks like without rendering it yourself: https://codepen.io/erikaja/pen/RNRVMyB


Where do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection?

Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers.

All I can think about is a quote by world famous video artist Nam June Paik: When to perfect, Gott böse ("God gets mad when too perfect", the original isn't exactly a full sentence and mixes English and German).


Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.


> It is like fast food, not every cares about farm to table

I mean, a "colorful fat choncker" website is literally the opposite of fast food - its slower to arrive, and focuses way too much on appearances.

In this analogy, the website using these ridiculous abstractions is more like Salt Bae or whatever idiotic trend has replaced him. All glitz, zero substance, slower, and for no apparent reason.

The fast food equivalent is stuff like the Google home page: it doesn't validate, is actively harmful to you, the community, and the planet but is immensely popular.


Everyone always says slower and bloat and bad etc etc but it is all relative. Not everyone is an eng who scoffs at waiting another 100ms.

I do like your analogy tho. It is better. Most people want that trendy experience or fast food. Still, both exist because the market demands it be so despite how much it tilts a subset.


I worked in first level IT support and I think most people don't even consider it consciously like that. They read the news at that page. That page changes. A lot has to happen to piss them off enough to make them go. They habitually click away fifty windows a day without reading them anyways.

But people do notice if something just works on a subconscious level and that colors their perception of your project/brand/page or whatever. Even my totally tech-illiterate father actively complains about junk interfaces like the one at Temu. But he goes there for the sweet deals. I just wonder if it wouldn't work out better for them if the page was snappy and allowed a person to visit more product pages.

And one mistake you make is to think you need a megabyte of javascript to create a junk look. You can easily do that with HTML and CSS alone, including animations and all.

The way I see it the causal arrow points in the other way: successful sites tend to get bloaty, but they do no et successful because of it, but despite it.

And by bloaty I don't mean it as a problem if the page does a lot. Bloaty means you use a intricate Rube-Goldberg-machine to in the end do very basic things. Like displaying a popup, which can be done with a single line of Javascript, but is for some reason done using the amount of code that would result in a veritable, heavyweight book if printed.


Except the correct way can be just as colorful, and it takes more effort to implement the bad way.


This is objectively not true, if it were the path of least resistance would mean everyone uses the option that is fastest and best.

It takes far less effort to implement the bad way. I think people take their own skill for granted. Maybe you can but most others cannot. Maybe they will learn or maybe they are happy to put food on the table and go home at 5.


When I say "implement" I mean the big pile of code in the library. I do not believe making that entire custom mechanism was easier. There's so much to it.

Everyone else following along and merely using it I blame less, but they shouldn't have picked such a bloated library.


The bad ways effort was already paid by someone else, though.


> How doable is it with vanilla css?

Under all of the framework complexity that specific look is still achieved with CSS. In fact, you could rip out the CSS they use with very little modification and pair it with a ~five-line React component that doesn't require any third-party imports.


Fun exercise! https://codepen.io/mcintyre94/pen/pvbPVrP

Everything in styles.css in that example maps to the vanilla input, so you just have to move them around a bit. Should work at least as well as theirs across browsers, because it's vanilla inputs and the same CSS.


The case is made. That's awesome.


  > - Make sure it looks the exact same across all browsers
  > How doable is it with vanilla css? 
It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript.

"Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work.

How well does this shadcn crap render in arachne? ladybird? netsurf? links? dillo? netscape 3? The latest version of chrome with user styles applied?

When you say "exactly the same", I assume you mean that the design only uses black and white, because some people might have black and white monitors, right? But you're also going to use amber-on-black because some people might have amber screen monitors, right? How do you plan on ensuring it looks exactly the same on a braille terminal?

Maybe you think I'm being silly. Because nobody uses monochrome monitors in 2026, right? So it's safe to ignore that and put an asterisk next to "exactly the same" (And also just forget that e-ink is a thing that exists).

(Just like how it was safe in 2006 to assume people would always have 800x600 or bigger displays, and nobody would ever come along using a screen with, say, 480×320 resolution)

What measures have you taken to ensure that your colours appear exactly the same across a bunch of different types/brands of monitors that render colours differently? Or, perhaps we should just add another asterisk next to "exactly the same"?

I could go on.

How many asterisks is acceptable before "exactly the same" isn't a thing anymore?

If "exactly the same on all browsers" is one of your goals, you are wrong. If your designer tells you that's what they want, they are wrong. If you ever tell a client that's what you're providing, you are wrong.


Particularly given that on a screen reader -- which yes is an example of a browser -- it doesn't "look like" anything at all


I think accessibility is one area where some of these components libraries can be helpful as they automatically include a11y features that might otherwise be ignored.


So many of these component libraries get a11y wrong, actually (or don't even try - mat-ui select comes with a big "don't use this" warning label)


Displaying the same thing on every monitor to the degree that monitor allows is well-defined. The browser may not be able to show some colors and the browser may decide to display things differently on purpose, but it's perfectly reasonable to want to unambiguously express what you _want_ the browser to display.


> Displaying the same thing on every monitor to the degree that monitor allows is well-defined.

In this case the website will not appear the same on every browser. Most browsers have a zoom function that the user controls which is an accessability feature. This changes how the website renders on the page.


That falls under displaying things differently on purpose


you misspelled "asterisk"


Exactly the same when rendered by the evergreen mainstream browsers. That's perfectly doable.


Author here.

You can do pretty much any styling!

I did a basic example because that matches what Shadcn does (black/white circle) but you can customize it a lot more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: