Re: [shadow-styling] First Draft of Shadow DOM Styling uploaded

On Sat, Feb 8, 2014 at 2:48 AM, Fran├žois REMY
<> wrote:
> I had a quick look at it. A few things there did not match your latest update on Shadow DOM [1] and I would like to understand why.
> Firstly, I never saw any discussion about the ":ancestor(...)" pseudo-class in the past, which allow selectors inside a shadow DOM to select elements outside the shadow DOM. Wow, I think we are breaking yet another level of encapsulation here in a way I don't like at all. A Shadow DOM should never have an impact on an another element in the visible DOM than the element it's applied on, otherwise I don't need a crystal ball to tell you the "mobile performance" will see a dramatic decrease in bowsers implementing your spec.

:ancestor() is exactly what was called :host() in my last update.
:host selected just the host element, :host(sel) selected if the host
or one of its ancestors matched the selector.

The problem was, it appeared to be relatively common to want to test
if *just* the host element had some feature.  You could do that, by
typing ":host(sel:host)", but that was stupid.  So, we split the
functionality out specially, so now :host() just looks at the host,
and the old :host() was renamed to :ancestor.

That all said, it looks like you've completely misunderstood what it's
doing.  It's a pseudo-class that *tests* the ancestors.  It's not a
combinator or pseudo-element, so it obviously can't *change* what
element you're selecting, it just filters.  I'm curious as to how you
got the idea that it actually selects the ancestors somehow, so I can
correct the explanatory text.

> Secondly, why do we need three shadow selectors? Three combinators were currently being discussed:
> - #a /shadow-descendants combinator (aka the ^hat) which selects all elements in the shadow tree of #a
> - #a /recursive-shadow-descendants combinator (aka the ^^cat) which selects all elements in a shadow tree contained in #a
> - #a /content combinator (aka ::content) which selects the elements of the document fragment rendered in lieu of the <content#a> element being selected.
> The current draft added a /shadow-children selector. I've no problem with that but I note you can already achieve it using "#a /shadow-descendants :top". I think that the names being chosen are not clear at all given we now have four combinators. As a beginner, I would have no clue what "shadow-all" and "shadow-deep" would do differently.

We added it based on (private) feedback from Jonas and Boris that they
wanted to avoid making it too easy to accidentally do a descendant
combinator.  To help with this, we added a true "child" combinator
that just jumped into the shadow tree rather than the child list, and
made it have the shortest name, so it's easy to reach for.

Name suggestions are *more* than welcome, by the way.


Received on Saturday, 8 February 2014 18:43:56 UTC