3 ms·
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web. We’re like 20+ years into web apps being a big
by pembrook 9mo ago
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift.
So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is).
If we could just agree on adding non-terrible cross-browser primitives for multiselect, popovers, modals, proper radio buttons, tabs, etc to the HTML spec and allow extensive CSS styling on every part of the element we could avoid these massive UI frameworks.
- mad182 9mo agoRadio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.
- oneeyedpigeon 9mo ago> So anybody building a web app... ... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out! What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?
- pembrook 9mo agoNative radios are notoriously hard to style consistently across browsers. You can do it with appearance: none, pseudo-elements, etc., but: - You re-implement focus rings, checked states, hover, disabled, error states. - You end up bloating your stylesheet incomprehensibly - Cross-browser differences (especially Safari) still leak through. - Controlled components, validation layers, animations/transitions, rich layouts are annoying and break accessibility - Turning native radios into radio cards for example breaks accessibility and keyboard navigation - Rows with icons, badges, subtext, etc. between the radio and label is a huge issue Hence why everybody uses Shadcn instead.