Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)

On Dec 3, 2013 9:16 PM, "Ian Hickson" <ian@hixie.ch> wrote:
>
> On Tue, 3 Dec 2013, Jonas Sicking wrote:
> > > >
> > > > Additionally, replacing the rendering rather than styling it is
> > > > hostile towards new platforms. If everyone had used Shadow-DOM to
> > > > build their own rendering for <select>s that would have made the
> > > > transition to mobile much more painful since you'd get a tiny custom
> > > > <select> UIs rather than a more platform-appropriate picker.
> > >
> > > Well, there's not much that can be done about that, as far as I can
> > > tell.
> >
> > Allowing targeting parts of the built-in UI using pseudo-elements would
> > go a long way. I.e. having a ::options-box pseudo-element as well as
> > other pseodu elements for other components of common implementations.
> >
> > This way the UA could ignore the style properties that it can't
> > implement or that doesn't make sense for its UI.
>
> Yeah, agreed. Again, with XBL2, the goal was to define some default
> bindings (in abstract, not concretely) that user agents were supposed to
> default to, and those bindings would specify pseudos that specific
> subparts mapped to (XBL2 had an xbl:pseudo attribute for this). You can
> actually see the remnants of this in the HTML spec's rendering section,
> where the widgets are defined in terms of the 'binding' property.

Defining the list of pseudo elements using a XBL2 binding or using prose is
just two was of doing the same thing. So yeah I think either would work.

The hard part is coming IP with the list I think.

> > > > And then there's of course the separate-but-related issue of being
> > > > able to style scrollbars, which is another reason websites create
> > > > sea-of-divs pages today. The reason this is related is that the
> > > > challenges styling form controls isn't really related to form
> > > > controls, but rather related to styling of UA-provided UI.
> > > > Scrollbars is another such UI.
> > >
> > > Right. We never developed this very far, but with XBL2 the idea was
> > > that we'd eventually let you override the binding of a '::scrollbox'
> > > pseudo, or some such.
> >
> > A scrollbar consists of multiple pieces, so you'll need more pseudo
> > elements. But yes, I think this is the right direction.
>
> Yeah, the idea is you'd bind to the scroll box to change the whole scroll
> UI, but you could also then override specific pseudos of the scroll box to
> style subparts of the default (or custom) scrollbox UI. This part was
> never very well developed though since the core of XBL2 was never picked
> up. But I think the same approach should probably still work with the
> newer Web components work, no? It needs to be specified and implemented...

Web components can't define pseudo elements. So no.

This sadly also means that you can't write a CSS which styles the default
UA UI if that is used, and styles an attached Shadow DOM if that is used.

I think this is a big problem, so far no one else seems to care. I'd be
happy if more people provided this feedback to the spec authors.

/ Jonas

Received on Wednesday, 4 December 2013 05:30:30 UTC