W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Shadow DOM and CSS

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 26 Nov 2012 15:57:28 -0800
Message-ID: <CAAWBYDD7xufSz8zinNBaoPQDB2j-QctobFeNN8_5xOApviN-+A@mail.gmail.com>
To: www-style list <www-style@w3.org>
This bit of cross-WG coordination slipped through my fingers; sorry about that.

The Shadow DOM spec hooks into CSS a little bit.  There are a few
parts where it's needed to specify how CSS interacts with it, and it
would be good to get the WG to vet that.

The relevant spec text can be found at
<http://www.w3.org/TR/shadow-dom/#styles>.  Basically, it breaks down
into only a few additions:

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.

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

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.

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.

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.

Expanding a bit, the way the Shadow DOM works is that elements in the
"light" DOM (normal children of the element, accessible via the normal
DOM methods), are suppressed when a shadow tree is attached to the
parent, but can be re-expressed by matching up with <content>
elements.  For example, the <details> element could be reimagined as
using the following shadow tree:

  <content select="summary:first-of-type" />
  <div class='wrapper'>
    <content select="*" />

When constructing the effective DOM that is used to build the render
tree, the first <content> element is replaced by the first <summary>
element among the element's children, while the second <content> is
replaced by all the remaining child nodes (including bare text nodes).

Now, from the CSS side, you'd like to be able to style things based on
where they got distributed to. In the trivial example above that's not
too necessary, but in a lot of more complex and realistic examples you
need it.

Currently, the Shadow DOM spec is using the reference combinator to
achieve this, based on my recommendation.  That is, say you wanted to
select the <summary> elements that ended up in the second content, so
you could give them a red background and see they were errors.
(Pretend for a moment that there's not a simple, easy solution like
"summary:not(:first-of-type)".)  You'd do it like this:

.wrapper > content /select/ summary { background: red; }

This will grab the correct <content> element, then flip into the light
DOM to select among the set of elements that were distributed into
this element.

This use of the reference combinator should be vetted by us.  I think
it's reasonable (or else I wouldn't have suggested it originally), but
there are some on our team who think it should be handled another way,
such as in this bug:


Received on Monday, 26 November 2012 23:58:16 UTC

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