I feel like half of all “custom-designed radio buttons and checkboxes” do two things:
- Make them bigger
- Colorize them
I always think of SurveyMonkey for having big chunky radios and checkboxes. And indeed, just poking at their interface quickly, even internally, the app uses has those all over the place:
I think it’s worth noting that if that’s all you are doing, you might be able to do that with zero CSS trickery. Just… make them bigger and colorize them.
Like…
input[type="radio"],
input[type="checkbox"] {
width: 3em;
height: 3rem;
accent-color: green;
}
That’ll chunk those suckers up and colorize them pretty good!
Except (obligatory sad trombone) in Safari:
We’re so close to having some very simple CSS to accomplish the main use-case for custom checkboxes and radios. But no cigar, that is, unless you can bring yourself to just not care about the Safari UI (it is still perfectly functional, after all).
If you do need to give up and go for a completely custom design, Stephanie Eckles has got you covered:
In related news, I always think of a “toggle” UI control as a set of 2 radio buttons progressively enhanced, but it turns out <button>
is the way, as Michelle Barker covers here. No native UI for slider toggle thingies, alas.
For me, a toggle is a checkbox. On = checked. Off = not checked. That’s how I’ve seen most people build them. Never seen people use radio or button for that
With a radio you can have a proper/different label for both sides would be my argument.
What Chris said. Think of a setting like this:
A checkbox wouldn’t make sense here. You’d be turning on or off “theme”, not switching between two distinct states (dark and light).
“unless you can bring yourself to just not care about the Safari”
Done.
I agree. Semantically, an on/off toggle is a checkbox, and would make more sense from an accessibility point of view. Using a radio button wouldn’t, as it doesnt’ allow the user to toggle it off (without weird trickery in Javascript), and using a slider with only 2 distinct values to replicate a toggle presents itself differently to people using things like screen readers.
I’m still new to css, but what’s the benefit of these methods over using
appearance:none
(and the vendor prefix versions as well) and then styling the checkbox/radio directly as needed?The profit is that this method is much simpler – you control look of the radio/checkbox with only 3 properties. If you use appearance:none, you need to “draw” the checkbox/radio back from scratch, including making the check mark shape (eg. using image) when checked etc.
try ‘transform: scale(2);’
This works in Safari but the UI elements get pretty blurry
CSS
accent-color
is supported and enabled by default in the Safari Technology Preview Release 135, so it will be landing in a future Safari release.The good news is that
accent-color
was added to Safari TP a couple of days ago, so should be with us very soon.https://webkit.org/blog/12040/release-notes-for-safari-technology-preview-135/
Why did you set their widths to
3em
, but their height to3rem
? Is that a typo, or a trick I don’t know about?Life just needs a little chaos.
(It’s a typo)
Thank you – neat to finally have a way to style pesky form elements enough to please the designer, without leaving the front end dev feeling grossed out