Re: <select> elements are the last of the system widgets to require hacky styling

Actually, radio buttons and checkboxes ARE customizable in Chrome.  Last I
checked, the HTML-based settings page has CSS for its checkboxes.

I agree, though, that there should be a clear specification for it.

—Zachary Yaro
On Oct 31, 2012 7:41 AM, "Sebastian Zartner" <sebastianzartner@gmail.com>
wrote:

> <select> is definitely not the last - the <input type=date> popup, for
>> example, works similarly.
>>
> Also radio buttons and checkboxes are not stylable by common browsers like
> Firefox and Chrome (while they are in IE and Opera).
>
> There should definitely be a clear specification for this.
>
> And I think the solution to this is pretty clear:
> UAs are responsible for how form fields are displayed. I.e. if a mobile
> device displays <select> options as modal dialog, it should simply ignore
> the styling. While desktop browsers can (and must) interpret them.
>
> That being said having a modal dialog for select options could still allow
> styling e.g. the borders, the background and foreground color etc.
>
> Sebastian
>
>
> On Wed, Oct 31, 2012 at 12:12 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> On Mon, Oct 29, 2012 at 3:30 AM, Aaron Hamilton <aaron@correspondwith.me>
>> wrote:
>> > I often-enough see people overflowing and masking select boxes to get
>> rid of that remaining system widget button on them, this is something that
>> bothers me (and restricts my work as well).
>> > It'd be nice to be finally trusted to style select elements and not
>> leave all my users scratching their heads...
>> >
>> > Is this something that's been considered already, and refused for a
>> practical reason?
>> > Anyway, I'm new around here(please don't eat me), and I hope that this
>> particular hack may be avoided in the future.
>>
>> <select> is definitely not the last - the <input type=date> popup, for
>> example, works similarly.
>>
>> We've wanted to be able to expose them for styling for a long, long
>> time, but have never figured out how to do so.  It's much harder than
>> it seems.
>>
>> If all you ever do is design desktop websites, for example, you'll see
>> approximately the same <select> styling everywhere.  There are some
>> platform-level tweaks, but it seems pretty easy to at extract a common
>> markup from them which can then be styled.
>>
>> As soon as you get to mobile devices, though, you see the problem with
>> this.  <select> on modern Android, for example, opens up a modal
>> dialog with the <options> represented as a list of labels and radio
>> buttons.  <select multiple> is identical, except with checkboxes.
>>
>> Styling that is appropriate for desktop <select> makes *no sense* for
>> this kind of mobile <select>.  It *might* be justifiable to extract a
>> common markup for all of them (though I don't know what other mobile
>> devices do), but letting authors *style* them is probably going to be
>> user-hostile - authors that only test on desktop browsers will apply
>> styles that might render the mobile version unusable (and I suspect it
>> would be fairly easy to do so).
>>
>> Moving to the other elements that generate special browser UI, like
>> "time" or "date" inputs, the markup and user experience is even more
>> variable.  Android's <input type=time>, for example, again pops up a
>> modal, with the nice system spinners for each element of the time.
>>
>> As much thought as I've given to the matter, I've never been able to
>> come up with a way to deal with these problems, and neither has anyone
>> else in the WG. Feedback welcome.  ^_^
>>
>> ~TJ
>>
>>
>