W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2013

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 3 Dec 2013 21:06:34 -0800
Message-ID: <CA+c2ei9Djsiv7TpGwQ94aqPvqMg8qo3bvTC93W7grpeMYOaDUQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHAT Working Group <whatwg@whatwg.org>
> > However the Shadow DOM spec gets us closer to one approach to it. It
> > lets you replace the rendering of an element with something more complex
> > than what CSS can describe.
> >
> > But there's still no spec that enables you to "turn off" the native
> > rendering of a form control and just use the normal CSS+Shadow DOM specs
> > to define the rendering.
>
> With XBL2, that was relatively straight-forward: you just used the
> 'binding' property, and the binding's shadow tree replaced the element's
> rendering. Why is it not the same with the Shadom DOM spec?

That might actually be the case with Shadow DOM, I might have been
misinformed.

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

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

/ Jonas
Received on Wednesday, 4 December 2013 05:06:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC