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

>
> <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
>
>