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

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

Received on Wednesday, 31 October 2012 16:59:06 UTC