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

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 14:40:00 UTC