- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 26 Nov 2012 15:57:28 -0800
- 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 stylesheets. 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: <shadow> <content select="summary:first-of-type" /> <div class='wrapper'> <content select="*" /> </div> </shadow> 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: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19684 Thoughts? ~TJ
Received on Monday, 26 November 2012 23:58:16 UTC