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

On Feb 20, 2014 5:49 PM, "Domenic Denicola" <domenic@domenicdenicola.com>
wrote:
>
> I agree that this approach makes sense and is a good potential route.
However, what I was initially wondering was: can we just use existing
shadow DOM constructs? E.g. could you style the slider with
>
> input[type="range"] /shadow/ .slider-thumb
>
> ?
>
> > 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.
>
> I am coming at this from a slightly different perspective. How can we
make shadow DOM not just a look-alike, but an actual layer in the layering
scheme?

I don't actually think what he is suggesting precludes this, i think he is
saying that maybe the shadow boundary can expressed such that some will
allow you to permeate through /shadow/ (or ::shadow-meh, or whatever) and
some would be "sealed" from css styling excerpt through named parts - and
that native elements could be expressed via the later.

Is that right?

We did have named parts at one time, i think that they turned out to have
the same "shadow-deep" problem with composibility. Maybe that's solvable.
But, would this be a CSS relevant only feature? I mean, with JS they can
puncture and pop right into the shadow subtree, to Alex's point.

>
> > Imagine I wrote something about the Extensible Web Manifesto here.
>
> ;)