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

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

From: Brian Kardell <bkardell@gmail.com>
Date: Thu, 20 Feb 2014 23:40:57 -0500
Message-ID: <CADC=+jcMB496mc-f=17cgHcRDZL07Mno6rS6vdxNKbMhqOdfPA@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: www-style@w3.org
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.
>
> ;)
Received on Friday, 21 February 2014 04:41:25 UTC

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