RE: Styling form control elements

From: Jonas Sicking [] 

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

I think we have somewhat divergent models of how I'd want to be styling this. More below.

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

No, not at all! That's why I wanted separate ::control and ::popout. Let me explain...

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

What I had in mind was more like this:

<div class="select">
  <span class="control">value 1</span>
  <div class="popout">
    <div class="option">value 1</div>
    <div class="option">value 2</div>

With the browser toggling display: none/display: block on the popout according to OS-specific behaviors.

I was about to give you a sample. I had it 95% done. But then the webpage I was using interpreted a backspace as a "Go Back," and when I pressed forward, all my work is lost. So hopefully you can get the idea without me having to re-create that :(. If not let me know and I'll give it another try. 

Along the way I discovered the following additional needs (eek, scope creep!)

- I indeed needed to style the <option> and the <option> hover state.
- I needed a way of telling if the parent <select> was "open" or not, so that the ::control could stay in a single visual state while the popout was visible, instead of changing as you hovered.

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

Right, I think there was a slight miscommunication. For C, I didn't mean "nuke all styles on the existing elements," I meant, "nuke all styles on the elements and shadow elements, but still expose to me an appropriate set of styleable shadow elements" (like ::control and ::popout).

Received on Saturday, 7 December 2013 19:57:58 UTC