Imagine a world in which the default form controls on the web did not suck. Picture it in your mind... In this world, the controls' styling:
-
Show this thread
-
Replying to @domenic
Disagree
with matching OS styles because the web has the power to look and be consistent on all OSs. Agree
on the need for better controls. I have been making websites for long time and now work on a browser and still need to check CSS tricks on how to style checkboxes.1 reply 1 retweet 5 likes -
Tho checkbox is a tiny problem - over the weekend I was inspecting the Twitter web client compose dialogue and the amount of work the devs had to do to make a slightly advanced text area with mentions and hashtags work is massive I'm writing
@gregwhitworth a 3 page email rn.2 replies 0 retweets 2 likes -
Generalising slightly from this, OS (rather than design system) coherence is something apps aspire to when they're tiny in terms of use. When they get big, they get to train users rather than the other way around.
1 reply 1 retweet 4 likes -
Replying to @slightlylate @_zouhir and
I'm sure someone at Apple will still defend the lack of SD standardisation/customisation for select because they get to insert their magic dial thing which is OS consistent. But let's be real: it's a bad UI.
1 reply 1 retweet 5 likes -
Replying to @slightlylate @_zouhir and
Hard to navigate, requires lots of high-precision movement to use well, scales to other form factors terribly. OS consistency, at the limit, is only as good as the OS paradigms, and they are often cast in amber while software marches forward.
1 reply 1 retweet 6 likes -
Replying to @slightlylate @_zouhir and
So the web should both reject slavish OS consistency (how much pain have we caused for <button> styling to defend this turf?) as well as the notion that browser provided impls are hallowed. They're just (badly layered) code that happens to be cheap.
1 reply 1 retweet 6 likes -
Replying to @slightlylate @_zouhir and
The real calling is to expose the guts: make all the infra that browsers ship for themselves but not for developers available on equal footing. Open the damned thing up
2 replies 1 retweet 8 likes
The benefit here, in case it isn't clear, is to undercut the usual arguments against customisation (which are real): that userspace components are bad at a11y, heavyweight, etc. They don't *have* to be, but we force that by keeping <input> a welded-shut disaster
-
-
agreed - I have a high level doc that goes over this. We're assessing the overall impact and team priorities at the moment, but if we do decide to tackle this I'd value your input. And yes, the story on the web for controls currently sucks, but it doesn't have to :)
2 replies 1 retweet 2 likes -
Replying to @gregwhitworth @slightlylate and
Developer and User Needs: <tabs> element <accordion> element <dialog> element (but good) <tooltip> element <input type="toggle">
2 replies 0 retweets 13 likes - 10 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.