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: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Wed, 31 Oct 2012 15:05:58 +0100
Message-ID: <CAERejNag6yEy2+ApOrBjdLYQzQzGYdon-B4qus2ZXT8bA6=Ozg@mail.gmail.com>
To: Zachary “Gamer_Z.” Yaro <zmyaro@gmail.com>
Cc: Aaron Hamilton <aaron@correspondwith.me>, WWW Style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Ah, right. You need to set -webkit-appearance to none. Then it's working.


On Wed, Oct 31, 2012 at 1:59 PM, Zachary “Gamer_Z.” Yaro

> Actually, radio buttons and checkboxes ARE customizable in Chrome.  Last I
> checked, the HTML-based settings page has CSS for its checkboxes.
> I agree, though, that there should be a clear specification for it.
> —Zachary Yaro
> On Oct 31, 2012 7:41 AM, "Sebastian Zartner" <sebastianzartner@gmail.com>
> wrote:
>> <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
Received on Wednesday, 31 October 2012 14:06:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:05 UTC