pico
pico copied to clipboard
UX issue with radiobuttons and checkboxes
Despite the fact that labels are clickable, the pointer doesn't change on mouse hover. Since mouse hovers on both the radios/checkboxes set cursor to "pointer", the same should happen on their labels as well. Changing the cursor on mouse hover on the labels would give a hint to users that they are clickable.

I had already thought about that, but I believe we can't do it without impacting the other labels (input text, select, etc.)
The only way would be to add a class, like .checkbox-radio-label. I would prefer to avoid it.
Thoughts?
We need :has() to be able to do this, but it's not supported yet.
Example: label:has([type="checkbox"]) { ... }
The only way would be to add a
class, like.checkbox-radio-label. I would prefer to avoid it. Thoughts?
To be very honest with you, as a UI/UX veteran my opinion (and the one of all the professionals in that industry) is that what's matter isn't the developer's preference but instead how the end-user feels. End-users don't care whether a class name has been added to the code or not. What they want is a UI that meets their expectations in terms of consistency and standardized logic across all the different UIs they encounter.
Would it be bad if "input text", "select", etc. also had pointer cursors? And if so, you could override it on those:
label { cursor:pointer }
select, :not([type=checkbox]), :not([type=radio]) { cursor:initial }
I find it useful if the label text for text-inputs also has a pionter , because when clicked the input gets focus.
I find it useful if the label text for text-inputs also has a pionter , because when clicked the input gets focus. @nuxodin good point
Would it be bad if "input text", "select", etc. also had pointer cursors?

The input type="text", just like textareas, must signify that something can be typed. This can only be understood thanks to the "|" cursor. Hand cursors are for inputs that are ONLY clickable. Messing around with that rule would be bad UX practice.
I find it useful if the label text for text-inputs also has a pionter , because when clicked the input gets focus. @nuxodin good point
Sorry but as explained above, that's very wrong. IMO, you should partner with a UX professional, or if you can't, then mimic the behavior of all the popular UIs which obviously tend to use the correct/standard UX rules and principles.
For example, GIThub.

@FranckSCTV The inputs should not have a pointer cursor, sure. Do you think it would be wrong if the input text labels have a cursor pointer on hover?
@FranckSCTV The inputs should not have a pointer cursor, sure. Do you think it would be wrong if the input text labels have a cursor pointer on hover?
Yep, that would be wrong. It's something you'd never see on a well known UI. Because, again, hand cursors (cursor:pointer) are for elements that are ONLY clickable. A label above an input isn't a clickable element. Only the input itself is supposed to be clickable.
@FranckSCTV There is no definitive "obvious", "correct", and "standard UX rule". If it was so obvious frameworks like Bootstrap and Tailwind, and especially browsers would have a pointer on checkboxes and radio labels. We collaborate voluntarily and freely here. Pico is a CSS library. We ship code. Feel free to open a Pull Request if you have an obvious and elegant solution.
@FranckSCTV There is no definitive "obvious", "correct", and "standard UX rule". If it was so obvious frameworks like Bootstrap and Tailwind, and especially browsers would have a pointer on checkboxes and radio labels. We collaborate voluntarily and freely here. Pico is a CSS library. We ship code. Feel free to make a Pull Request if you have an obvious and elegant solution.
Of course, there are debates even within UX professionals, I agree with that. The libraries you're citing, for instance Bootstrap, chose to mimic the browser's behavior on radios and checkboxes (but not on buttons interestingly).
In your library, you're using a non conventional approach : pointer on radios/checkboxes but not on their labels.
What I propose is either you add a pointer on both OR you remove the pointer on both (like bootstrap). The second option wouldn't require additional code so I recommend that route in your case.
What do you think? Sounds elegant enough IMO.