W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[shadow-styling] Named parts, styling built-in form controls, and shadow styling (was Re: Goals for Shadow DOM review)

From: Edward O'Connor <eoconnor@apple.com>
Date: Thu, 20 Feb 2014 14:40:09 -0800
To: www-tag@w3.org, www-style@w3.org
Message-id: <m2txbt5rxy.fsf@eoconnor.apple.com>
+www-style, -www-tag for replies to avoid cross-posting

Hi,

Domenic wrote, on www-tag:

> [C]an shadow DOM be used to explain existing elements, like <video> or
> <input type="range">, in terms of a lower-level primitive?
[…]
> [I]t could lead to attempting to loosen the boundary, so that authors
> *could* use standard shadow DOM mechanisms to style <select> or
> <video> elements.

Suppose we had a generic notion in CSS of "named parts." Elements may
have zero or more named parts. Each named part has a name[1] and can be
selected with a ::part(name) pseudo-element.

We could then base the long-desired "styling native form controls"
feature on this building block. We could take a look at the existing,
engine-specific form element pseudos to figure out what to include in
the initial draft. For instance, WebKit lets you style the slider thumb
of <input type=range> with the following:

    input[type=range]::-webkit-slider-thumb

If CSS had a named parts primitive, we could move to exposing this as

    input[type=range]::part(slider-thumb)

and all engines whose <input type=range>s have sliders with thumbs could
support this. If you're on a platform whose native range widget doesn't
have a slider thumb, this selector doesn't have anything to match, so
we're good there.

Now, back to Shadow DOM. The Shadow Styling spec could define a way for
Shadow DOMs to hook into the named parts mechanism. Say you have a <div>
whose Shadow DOM exposes a part named foo. Styling this becomes:

    div::part(foo)

I really like how the syntax is parallel to the engine-native form
controls case, but simultaneously the syntax doesn't imply that the
engine-native form controls are built with Shadow DOM. If you're
implementing a new form control with Shadow DOM[2], styling your custom
control's parts is syntactically identical to styling native controls.
Imagine I wrote something about the Extensible Web Manifesto here.

Note that I'm not proposing this as a *replacement* for other mechanisms
for selecting parts of shadow trees, but simply as one of the tools in
the toolbox for component authors. In the private-flag-is-on case, maybe
the /shadow{,-all,-deep}/ selectors fail to match but ::part(name)
continues to work?

I guess this is three specs: Named Parts, Form Controls (should this be
in CSS UI?), and part of the Shadow Styling module. Or we could fold the
first two together or whatever.


Ted

1. And you'll also want an optional whitelist of CSS that can apply to
   it. See for instance the styling of <input placeholder> today.

2. See this thread on public-webapps:
   http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html
Received on Thursday, 20 February 2014 22:40:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC