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

On Tue, Dec 3, 2013 at 9:30 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

That's simply not true. Where'd you get that?

http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements
http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/

:DG<

Received on Wednesday, 4 December 2013 05:40:00 UTC