RE: Styling form control elements

From: Jonas Sicking [mailto:jonas@sicking.cc] 

> The control that you see by default can simply be targetted with "select", no?

Hmm, I suppose so. Although I have been unable to get rid of the arrow (which I consider part of that control) with CSS. And, I have found that styles applied to the <select> often have effects on the popout, which is undesirable. So that is why a ::control made more sense to me.

> The three pieces that are often brought up are:
>
> 1. The popout
> 2. The little down arrow that's displayed in the default control, usually on the right-hand-side.
> 3. The part of the default control which displays the currently-selected option.

I think this level of granularity, separating 2 and 3, is where we start to get into trouble. Yes, ideally I would like to style them separately. But in practice, just the ability to completely nuke the existing styles, and end up with something equivalent to <div>selected option text</div>, would be enough to allow us to build our own styles. We can create our own arrows with (multiple) background images, or ::after.

> To make matters somewhat more complex, <select>s can also be rendered as a list rather than as a popout. Do the above pseudo elements map to anything in such a <select>?

Ah right, easy to forget. I'd say leave any such mapping out of a minimal solution. In fact I think a <select multiple> doesn't have any real "parts"; just the <select> container and the <option>s. Maybe you'd want a :selected pseudo-class on the options. But in reality styling <select multiple> is much less urgent.

> There are actually 3 different modes here:
>
> A) The default rendering. Many times this can not be described using CSS, and so can't always be styled with CSS
> B) Fallback rendering that still renders a full form control, but which is rendered using shadow content and CSS and thus can be styled using CSS.
> C) No special rendering at all. I.e. the <select> is just an inline element, as are the <option>s inside it.
>
> ...
>
> There is currently no way to make gecko use C.

This is a big problem, as what we want is the ability to just nuke the styles and replace them with our own.

> I believe that webkit has similar behavior. Though using -webkit-appearance: none of course.

Not true, which is part of why <select>s are so much more styleable in Chrome than they are in Firefox. http://codepen.io/anon/pen/BFtgD shows that WebKit/Blink uses C, as far as I can tell. In particular the arrow disappears, which we cannot accomplish in Gecko. In fact, <select> can be styled perfectly in WebKit/Blink... at least as long as the user doesn't click on it. Once they do, the mostly-unstyleable "popout" portion is revealed, and the illusion is lost. (I say "mostly" unstylable because some things, like background-color, seem to get inherited from the <select> to the popout.)

> So when you say, "default <div> styles", do you mean B or C?

Definitely C, although I suppose "default <span> styles" would be more appropriate.

> I think there are use cases for explicitly triggering the C rendering.
> I'm not sure if there are for triggering the B rendering. The auto-fallback might be good enough. But I'm really not sure.

I agree that C is much more useful than B. I do not know what the point of B would be, really. I don't think anyone consciously chooses to get the ugly semi-default buttons you get by adding `background-color: whatever` to a button; they instead do a complete overhaul with new colors, new border, new box shadow, new border-radius, etc.

>> - No specification (for now) of individual items inside the ::popout.
>
> Not even the <option>s?

Meh, would be nice, but feels like it'd be pushing it. Maybe not though. I guess it is pretty important to be able to control e.g. hover color/background.

> I'm certainly interested in nailing this stuff down. And I know many others within mozilla are too.

Cool! It'd be great to finally crack this nut.

Received on Saturday, 7 December 2013 03:26:13 UTC