Re: Styling form control elements

On Fri, Dec 6, 2013 at 7:25 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> 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 reason you've been unable to get rid of the arrow is because it's
a separate box that is rendered inside the outermost box. That will
remain true even if you use "select" or "select::control" to match the
outermost box.

This is why I believe you want a new pseudo-element to select this
separate inner box, so that you can change it's rendering or hide it.

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

Do you really think you can build a good <select> UI using just the
elements elements available in the DOM plus CSS? I.e. using just an
outer element <select> element and then one inner <option> element for
each value? In gecko we end up adding a bunch of hidden shadow DOM as
well as some logic not expressible in CSS.

Granted, our UI has been designed by engineers and not designers :)

However I'd be curious to see what your UI would look like. Should be
easy to do by simply using a DOM like.

<div class=select>
  <div class=option>value 1</div>
  <div class=option>value 2</div>
</div>

Would you mind putting together a prototype of what you had in mind?

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

Agreed. Though I think starting with a couple of simple elements like
this is a good start. Once we embark on things like <input type=date>
we're going to be in a much bigger world of hurt :).

>> 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 agree. But I think this is only part of the problem since often
times styling the built-in controls means styling the anonymous
elements that are there, not getting rid of them. At least that was my
vision.

But I agree that C is important too.

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

Exactly. So webkit seems closer to C, but still is definitely not C.
If you did C there would be no popout at all, and all elements would
be rendered directly in the page, no?

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

If all we want to do is C then that's super easy really. All we need
to define is that "appearance: none" removes all UA styling and
reverts the control to be just plain inline (<span>) elements. No new
pseudo classes needed at all.

Is that enough?

That does mean though that we're back to something I was saying in a
separate thread [1]. That if you want to style anything about a
built-in element, that now means that you are responsible for fully
building that element yourself. Is that ok?

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-December/041691.html

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

The point would be that from there you can style it using CSS to have
the look-and-feel of your page.

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

The question is, will people still use it if they can just style the
normal control, but once the popout is displayed, things now look like
the UI designer was the color blind bastard child of picasso (i.e. the
one that me and bz designed as the built-in browser UI).

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

I could not agree more!

I'm really not sure which problems to attack, hence I'm asking so many
questions. I do believe we have to do a thorough job though, not just
a minimal thing. The minimal thing will still mean that people choose
to build their own controls and complain that styling form controls
suck.

/ Jonas

Received on Saturday, 7 December 2013 07:07:16 UTC