> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form.
A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS.
For example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article).
> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
What the fuck? Just use the actual goddamn checkbox. You can set colors with CSS, but also, it will work in exactly the same way as all the other checkboxes on the user's system. It will respond to keyboard and other input shortcuts the same way as all the other checkboxes they use. It will work with any accessibility devices the user has in the same way as all the other checkboxes they use.
Don't reinvent standard controls just because they're not "customizable" enough. Function is more important than form, and the standard control has a lot more function than you're probably aware of. Also, the user already knows how the one on their system works, because they've already used one hundreds of times.
And the same goes even more so for controls which are more complex than the checkbox. Which is, uh... checks notes... all of them.
The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this - certainly not Firefox on the Android phone I'm typing this from, nor the Windows box IT wants me to use for work, nor the Linux VM running inside that.
Especially for web apps, writing them so that they look good on every browser with default styling for every element is... Difficult.
Not to mention, users often use the same app from different browsers (laptop, phone, tablet), and are much more easily confused by the different styles of each device and browser than if the app itself is consistent, but different from other apps.
Edit to add: I'm very curious if you can find some major sites that do actually use the default checkbox controls - Google doesn't, YouTube doesn't, Apple doesn't, Wikipedia doesn't, Mozilla doesn't (though I did find a default radio button on their donate page), Microsoft doesn't. Even HN uses plenty of default controls, but still you'll see some custom controls, such as the upvote/downvote buttons.
> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this
We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.
I don't think that is actually a good thing. I much rather have people less tied to one particular ecosystem, and preventing barriers to moving from one OS to another.
Instead they get to learn new ways of doing things with every single application they use regardless of platform and still have to deal with platform issues. Yay for progress?
However, they also benefit from innovation in how those widgets work, rather than being locked to historic buttons because the committee can agree on on pixel change a year
By moving from one OS to the other you really mean Windows/OSX/Linux, right? Because thanks to modern web(browsers) you can almost but forget using another one, regardless of someones checkbox design.
"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.
One of the things that the words "just compromise your design" make clear is that the focus is on the designer, not the users. Which in my view is often the problem. It's especially hollow here given that much of Karellen's point is about what's best for the users.
It is for things like checkboxes. If your design requires checkboxes to be special and different from everyone else's checkboxes, your design is wrong.
Don't reinvent well known controls. Stop doing it. You can give it a border color and an accent color (check out the new accent-color CSS property) and for the rest you leave it alone.
This is completely silly, and no one does this. If I'm going for a square design, I'll want my checkboxes to be square, not rounded squares like Firefox offers for example.
Try to extend this idea to a game menu and see how much sense it really makes to you: would anyone really want default browser checkboxes in an otherwise medieval styled game UI, for example?
Also, if you truly believe that all checkboxes in all apps should look exactly the same (per browser/OS, and except for color), then why not extend this to other aspects of design? Why even allow different sites to use different fonts? That is much harder to adjust to than a different roundness on checkbox corners.
> And the same goes even more so for controls which are more complex than the checkbox.
HTML has a lot of virtually useless controls due to their limited styling. And yeah, sometimes you want custom-looking checkboxes, because you just fucking do and design matters. Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about -- I recall a time where zooming in in Chrome wouldn't change the size of checkboxes!
Those aren't even the most egregious examples, to be honest.
> Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about
In which case, people with accessibility needs won't be using that browser. And that's the whole point. The user can pick whichever browser works best for them, and implements the standard controls in the way they want. (Or, in the way that sucks the least, out of the browsers available to them.) And if they decide to get a better browser (different engine, or even just a major upgrade to the current one) suddenly all their websites work better. More importantly, they all work better in exactly the same way, so they only have to get used to any differences once, rather than for each and every website.
If you go and write your own version of a standard control which implements it that way you want, you take that away from the user.
HTML allows you to specify the semantics of the controls you want, and have the user-agent bother with the details about how it works. That's going to be more lightweight, more performant, and more user-friendly for more people than any alternative you bodge together yourself.
The best thing about using standard controls for things in that as things get better. You get it for free. The zoom bug gets fixed.
I have a bunch of legacy custom controls I deal with regularly because things like color pickers were not cool enough in 2009. The down side is that in 2022 they regularly break and require dev time to fix so some report that gets run once a year works correctly.
I agree, I know eventually the datalist won't lag on scroll with even just 100 items in their datalist control, and that they'll name their dropdown picker to something other than "-webkit-calendar-picker-indicator" since it's misleading https://jsfiddle.net/klesun/mfgteptf/ If I sound passive it's because I assumed a native control/component would be performant and switched out a lot of controls for it only to have to revert back to a custom solution. But ultimately they will be fixed and it'll happen to us transparently which is nice.
> So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
Because HTML is the only way to do a checkbox?... Even if you use JavaScript, at the end of the day you'll have to generate HTML for it to render... so then why go through the effort of using JavaScript for a checkbox at all?
A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS.
For example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?
I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article).
[0] https://www.w3schools.com/howto/howto_css_custom_checkbox.as...