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

I agree with Brad that it would be easier address the topic of styling the
un-clicked/un-tapped <select> element.  I personally find it very annoying
to try to style that between browsers and even in the same browser across
OSes (e.g., Chrome on Windows allows different styling from Chrome on
Linux).  I cannot think of any good reason to prevent the styling of those.
 The arguments made for not styling <option>s on mobile are especially not
valid for <select>s because, at least on iOS and Android, the in-browser
<select> appearance does not even match the appearance in native apps.


—Zachary “Gamer_Z.” Yaro


On 31 October 2012 12:58, Brad Kemper <brad.kemper@gmail.com> wrote:

> It seems like most of this conversation, beginning with Tab's answer, has
> been about styling OPTIONs. But the original question was just about the
> un-clicked/un-tapped SELECT element and its icon on the right (which
> authors were hiding via 'overflow: hidden'), which is generally consistent
> (with variations) across browsers and platforms, including mobile. I think
> that question can be answered more simply.
>
> If we are going to get into the styling of OPTION, we should also consider
> styling of OPTGROUP and styling of its 'label' attribute.
>
>
> On Oct 31, 2012, at 7:39 AM, Hugh Guiney <hugh.guiney@gmail.com> wrote:
>
> > On Wed, Oct 31, 2012 at 7:12 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> >>
> >> 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).
> >
> > Safari for iOS renders <select>s as a scrollable wheel of <option>s
> > that expands upward from the bottom and stops midway, forming a
> > split-screen view. A checkmark (not a checkbox) indicates the selected
> > option. For <select multiple>, it's the same thing, but with multiple
> > checkmarks. (<input type=time> is rendered similarly, but with
> > separate wheels for hour, minute, and period.)
> >
> > Certainly distinct from either desktop or Android, but I think
> > extracting a common markup would still be pretty straightforward.
> > Essentially, they all consist of a vertical stack of <options> with
> > individual selection indicators: highlights, checkmarks/boxes, or
> > radio buttons. The "wheel" effect on iOS seems to just be a vertically
> > scrollable area with a gradient overlay for effect, so that's not too
> > different. Whether it's a split screen or pop-up can just be a matter
> > of positioning.
> >
> > I don't think it'd be particularly user-hostile to allow at least some
> > author control over this. At least, not moreso than say, custom fonts,
> > or pure blue text on a pure red background. I could see it being
> > analogous to list-style properties. Just thinking out loud:
> >
> >    select {
> >        select-style-type: checkbox | radio | indicator;
> >        select-style-indicator: '\2713' | url('/img/check.png');
> >        select-style-highlight-color: #000;
> >    }
> >
> > On Wed, Oct 31, 2012 at 7:38 AM, Sebastian Zartner
> > <sebastianzartner@gmail.com> wrote:
> >> 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.
> >
> > This seems sensible to me. Although I would probably qualify it.
> > Desktop, iOS, and Android really only diverge in renderings once the
> > select box has focus. Up until then, they all look essentially the
> > same. So, they should probably, at the very least, not ignore style
> > rules that affect in-flow rendering, like the bg/border/padding, the
> > expansion button arrow (or ellipsis in the case of iOS's <select
> > multiple>). Out-of-flow renderings, i.e. the expanded versions, could
> > be left to the UA. They can respect author styling to whatever extent
> > makes sense, or just override it completely.
> >
>
>