From: Jonas Sicking [mailto:[email protected]]
> 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>
</div>
</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).
