Re: Styling form control elements

On Tue, Dec 10, 2013 at 3:42 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
>> I'm not sure I understand this. If you want the ::control to render the same way no matter if the select is "open" or not, then why do you need to test for that state?
>
> Right, what I meant was: normally, when the select is "closed," I want a hover state for the ::control. But when it is open, I do not want hovering back over the ::control to do anything visual. So my ideal selectors would be like:
>
> ::control {
>   background: blue;
> }
>
> ::control:hover {
>   background: green;
> }
>
> select:open ::control:hover {
>   background: blue;
> }
>
> or similar.

Makes sense. Though technically the user won't generally be hovering
the ::control when they hover the popout. Even if the pixels overlap,
I believe that CSS says that you are just hovering the topmost element
and its ancestors (or maybe that's just what all browsers implement).

However the user could still hover the ::control if it sticks out
under the ::popout.

>> I would also think that you need properties to position the ::popout. XUL used to have a really cool way of allowing you to anchor an element against another element. It would let you select which corner of your positioned element should be aligned to which corner of your anchoring element. Details at [1].
>>
>> We should be able to do exactly the same thing in CSS as long as we limit it to positioning child elements against their parent elements. We might also need to allow adding an offset as to account for borders and shadows etc.
>
> Sounds like a hard part...

Hard in what sense? I'd prefer to ask implementors rather than assume
that it's hard for them to implement if that's what you mean. (I can't
speak for the mozilla layout team here).

But I'm fine with postponing this. It seems like something that could
replace piles of JS in many cases, but it's mostly orthogonal to most
of what we're talking about here I suspect.

>> That's what B is.
>>
>> ...
>>
>> However there's not always pseudo elements that allow you to target
> the shadow elements. And where there is, those pseudo-elements are
> non-standard.
>
> Ah, that's a more correct way of looking at it; thanks. I was thinking of appearance: none as a switch that would apply all the way down the shadow tree, which it clearly doesn't (at least in Firefox; it does seem to in Chrome). As long as I can nuke that darn Firefox arrow...

I think it does apply down the tree. I.e. applying "appearance: none"
to the <select> also means that the <options> render without
OS-styling applied.

However it's still not option C which would represent rendering of a tree like

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

Which appears not to be what you're asking for.

Though I feel like we're being inconsistent here. It seems arbitrary
that applying "appearance: none" removes the arrow, but still keeps a
bunch of other styles. Specifically it still keeps the styling that
renders the selected option value, and it keeps the styling that hides
and positions the popout as needed.

I know you hate that arrow, but I'd rather come up with a set of more
generic rules than equating stylable formcontrols with hiding the
arrow ;-)

Potentially the answer could be to say that "appearance: css" creates
a control rendered entirely using CSS and thus styleable using the
various proposed pseudo elements.

However "appearance: none" actually renders C, i.e. only the elements
that are in the DOM as described with the markup above. This wouldn't
be useful for a <select size=1>, but it could be useful for <input
type=text> or other form controls.

/ Jonas

Received on Wednesday, 11 December 2013 00:40:32 UTC