Re: Styling form control elements

On Sat, Dec 7, 2013 at 11:57 AM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: Jonas Sicking [mailto:jonas@sicking.cc]
>
>> 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.

Actually, I think our mental models are surprisingly aligned. Which is
great! More below.

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

Ah! This is very similar to what I had in mind. I had imagined.

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

I.e. exactly the same but with an extra styleable "hook" for the down
array clickable thingy.

However using ::after to create such a down arrow seems reasonable. It
does make some styling harder, like if you want to have separate
borders around the "control" and the arrowthingy. But arguably that's
a shortcoming of CSS and not something we should work around here.

So dropping the arrowthingy element seems fine.

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

Seems fine. I think we're on the same page.

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

I don't think this is scope creep at all. As an implementor, I'm much
less interested in implementing a styleable-formcontrols feature that
is so minimal that it won't get used, than a more complex, but
comprehensive enough solution that it's actually solving people's use
cases.

> - I indeed needed to style the <option> and the <option> hover state.

option:hover should just work, no?

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

I don't mind adding a pseudo-class which only matches if the <select>
is "open" though. I just didn't understand the use-case.

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.

[1] https://developer.mozilla.org/en-US/docs/XUL/PopupGuide/Positioning

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

That's what B is. I.e. we still keep a few shadow elements around as
to enable more rich styling. But we render those style elements using
CSS so that they can be fully styled by the web developer.

Option C is to nuke all shadow DOM and just render the raw elements.

B is already supported in all browsers I tested (didn't test IE).
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.

/ Jonas

Received on Tuesday, 10 December 2013 23:31:16 UTC