W3C home > Mailing lists > Public > www-style@w3.org > October 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 31 Oct 2012 12:12:16 +0100
Message-ID: <CAAWBYDAbwhxaeQpRtY9aa-CDkg8bgrmOe98fnU+d-m81YCg4Eg@mail.gmail.com>
To: Aaron Hamilton <aaron@correspondwith.me>
Cc: www-style@w3.org
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.  ^_^

Received on Wednesday, 31 October 2012 11:13:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC