I never understood why designers design radio and checkbox inputs like that. I guess the standard design is too much accessible.

Looks like optimised for a touch interface, with tap-friendly design.

Buttons became even larger in mobile after UI research found that also cats and dogs can use that, but need larger tap targets due to the size of their paws, see https://nngroup.com/articles/... and https://nngroup.com/articles/....

@Fast-Nop It's a desktop version.

@Lexter mobile first, no one cares about desktop viewers anymore.

@Lexter Then I'd blame these shitty CSS frameworks such as Bootcrap or Tailwind which pollute the HTML with presentational classes so that you can't use CSS as intended for swapping out design elements in different views.

CSS frameworks are by people who failed to understand what CSS and HTML are even about and who shouldn't be making websites - but the competence bar in web dev is incredibly low.

@C0D4 In fact, more than 40% of this client's users come from the desktop. I think it's the job of coders and designers to reflect the situation of a particular client. To say that only mobile devices matter is nonsense and lazy statement.

We can design two versions. We should.

I hate this. Add proper visual clues at least, like goddamn checkmarks, shadows etc. a simple border around the group/backgorund for it in a color of an inactive button does fucking wonders.

@Lexter Actually, it would just be a few media queries in CSS and re-defining some CSS classes. That's easy with semantic markup and semantic CSS classes, but impossible with presentational markup.

@msdsk I resonate with that sentiment. We have so many options for creating a website that guides the user well through the process of using it. Yet, we resort to shortcuts that we know can't work. Or at least work to the highest degree possible.

Btw., this kind of fuckup is also why we see hamburger menus on desktop instead of just having a left-side menu for desktop and CSS-transforming that into a sticky-top menu toggled with the hamburger.

@Fast-Nop

Which is even more infuriating because adding desktop style menu takes like three minutes. It's just pure laziness and disregard for usability.

@Fast-Nop Yes, and it's actually not that much extra work with a well-designed workflow. I think some designers forget that designing a website is not about their personal preferences.

@msdsk It's only that quick if you leverage semantic markup AND semantic classes. With presentational classes, the markup settles the layout already.

That's in no way different than the shitty 1990s markup from before CSS, and it's sad that people abuse CSS just to continue ways that were already bad and outdated 20 years ago.

@Fast-Nop Semantics, a rule that should be law for the coder. What the heck, it's not a problem if he knows what he's doing, but what's the point if he gets a design that: on the left are the radio button, on the right the send button... They are the same.

@Lexter Holy crap, that's another serious UI fuckup. I wouldn't even be astonished if you looked under the hood and found that it's actually just DIVs with JS handler to fake the native elements. Or some stupid, unsuited shit like anchor tags.

@Fast-Nop My code is still semantical as it should be. Just the design, the look is... I have no words. As i said, i do what i can. Under the hood it is just normal, quality code (left just labels and radios, right is just input submit, nothing more). But... what is the point. Only screen readers will be happy.

@Lexter Ah, I didn't get that it was the design department fucking up your code on app-level through stupid design.

@Fast-Nop I forgot to mention that. You know, anger, emotions...

I don't see any radio buttons or checkboxes.

Literally the only thing, Microsoft did right was their extremely boring and highly accessible Windows NT GUI design.

Many web designers hate software UI standards and will gladly forego clarity to make something look more pretty