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

Ah, right. You need to set -webkit-appearance to none. Then it's working.

Sebastian

On Wed, Oct 31, 2012 at 1:59 PM, Zachary “Gamer_Z.” Yaro
<zmyaro@gmail.com>wrote:

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