Re: Shadow DOM and CSS

Here's an update on what things have changed with regards to the stuff
shadow DOM needs from/in CSS.

On Mon, Nov 26, 2012 at 3:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 1. The behavior of scoped stylesheets.  This is already specified in
> the Cascade module - it's just that "unscoped" stylesheets in a shadow
> tree are implicitly scoped to the shadow root.  It looks like a chunk
> of the Shadow DOM's spec surrounding language can be removed, once
> fantasai and I finish up a little bit more work in the definition of
> scoped stylesheets.

This is clearer now - a stylesheet inside of shadow DOM isn't even
really a "scoped" sheet, it's just a normal sheet in a separate
context.  Shadow trees are fully separate from the enclosing light
DOM.

> 2. The @host rule, which switches the selectors of contained rules
> from scope-contained to scope-filtered
> <http://dev.w3.org/csswg/selectors4/#scoping>.  fantasai and I will
> specify this soonish, as part of our more general treatment of scoped
> stylesheets.

Similarly, this now switches contexts - selectors inside a @host rule
match against the enclosing light DOM.  They're also scope-filtered,
with the host element as the scope.

> 3. Some rules about how sheets can be scoped to a shadow tree, which
> acts like a mini-document.  This is largely a DOM issue, or perhaps
> CSSOM.  Should be uncontroversial.

This is now more implicit.  I'm not sure if anything actually needs to
be done at the OM level.

> 4. Rules about how selectors from the outer page might or might not be
> able to cross into the shadow tree, based on whether the tree is
> sealed against styles or not.  Again, should be uncontroversial.

This still needs to be done, but it should be simple and easy.

> 5. The hard one - the use of the reference combinator from Selectors 4
> <http://dev.w3.org/csswg/selectors4/#idref-combinators> to handle
> targetting nodes based on distribution.

This has been replaced.  Discussion between Dimitri, fantasai, and I
led to the conclusion that Selectors seem to have an implicit
constraint that the final set of matched elements must be a subset of
the elements matched by the last compound selector (the first one to
be processed if you resolve Selectors in a right-to-left manner as
browsers do).  This constraint is only broken by pseudo-elements,
which "switch context" to a new tree, which is exactly what shadow DOM
needs to do.

So, the shadow DOM spec has introduced a ::distributed(<selector>)
pseudo-element to handle this.  It applies to <content> elements in
the shadow DOM, and the selector is resolved against the light DOM
elements distributed by that <content> element.

On the flip side, when you're inside of a @host rule, you're in the
light DOM context, but it's reasonable to want to then descend back
into the shadow DOM context.  (For example, you may want to style
shadow elements differently based on an attribute on the host
element.)  To handle this, we've introduced a ::shadow(<selector>)
pseudo-element, which applies to the host element and resolves the
selector against elements in the shadow DOM.  (This only applies to
the host element *from within the shadow DOM stylesheet* - it doesn't
let a light DOM stylesheet reach in and arbitrarily style elements in
the shadow DOM, as that breaks encapsulation.)

I'm not sure that the spec has been fully updated to contain these yet.

~TJ

Received on Sunday, 17 March 2013 20:26:14 UTC