I was reading Anna Kaley’s “Listboxes vs. Dropdown Lists” post the other day. It’s a fairly straightforward comparison between different UI implementations of selecting options. There is lots of good advice there. Classics like that you should use radio buttons (single select) or checkboxes (multiple select) if you’re showing five or fewer options, and the different options when the number of options grows from there.
One thing that isn’t talked about is how you implement these things. I imagine that’s somewhat on purpose as the point is to talk UX, not tech. But how you implement them plays a huge part in UX. In web design and development circles, the conversation about these things usually involves whether you can pull these things off with native controls, or if you need to rebuild them from scratch. If you can use native controls, you often should, because there are tons of UX that you get for free that that might otherwise be lost or forgotten when you rebuild — like how everything works via the keyboard.
The reason people chose “rebuild” is often for styling reasons, but that’s changing slowly over time. We’ve got lots of control over radios and checkboxes now. We can style the outside of selects pretty well and even the inside with trickery.
But even without custom styling, we still have some UI options. If you need to select one option from many, we’ve got <input type="radio"> buttons, but data and end-result-wise, that’s the same as a <select>. If you need to select multiple options, we’ve got <input type="checkbox">, but that’s data and end-result-wise the same as <select multiple>.
You pick based on the room you have available and the UX of whatever you’re building.
I have a question about that. If you have too much
<input type="checkbox" />on desktop maybe you want to transform these inputs to a<select>type on mobile. There is a way of doing that only with CSS? All the implementations that I saw always rely on JavaScript.That’s an interesting situation. I don’t think CSS alone could do it. Even if you toggle the display of different sections of the forms HTML with CSS, those form elements are still there and will likely submit. At least with JavaScript you could remove the others from the DOM or change something about them to prevent them from submitting and being accessed with assistive technology. But even then, you’ll have to be really careful that the form submits data in the same exact format.
One of the solutions I can think of is to make the element you do not need to display have CSS properties of the kind:
{
display: none,
/* OR */
opacity: 0,
width: 0,
height: 0
}
However if you really want to remove some HTML elements (not style them out) depending on the device then you will indeed need JavaScript, as CSS can only apply style to HTML elements, not remove or add them.
I would be careful with
<select multiple>since people tend to not know how to select multiple items from the list with unselected elements in between (on desktop). In the example above this would be selecting “Choice 1” and “Choice 3”, but not “Choice 2”.On mobile it seems to be rendered as a list of checkboxes when the element has focus.
I agree with this completely, and tend to avoid
<select multiple>. Even if a user knows how to select multiple items, it’s still easy to make a mistake (accidentally hit shift instead of ctrl or vice-versa). Plus, with a list that exceeds the size of the select control, a user cannot see the entirety of their selection, which can easily lead to a user unknowingly submitting the wrong data (especially true on edits).Sort of – as the linked NNG article points out:
(my emphasis) So yeah, the data you get is the same, but in terms of “end result”, it kinda depends on how you define that – does it include the UX value of obviousness?