21390 2013-03-25 19:26:15 +0000 [Shadow]: add support for styling shadowDOM contents based on host element 2013-07-17 22:12:35 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED DUPLICATE 20957 P2 normal --- 14978 21499 1 sorvell dglazkov dominicc hayato tasak public-webapps-bugzilla oldest_to_newest 84940 0 sorvell 2013-03-25 19:26:15 +0000 It should be possible to style shadowDOM contents based on a selector the host element matches. In general, it is common to define a set of theme styles that apply if a given ancestor selector matches. If nodes within a shadowDOM can be styled conditionally based on the host element, then shadowDOM can easily support this design pattern. At a recent discussion, a ::shadow() pseudo-selector was proposed for this purpose. It would be used in an @host rule as follows: @host { /* match .foo shadowDOM nodes inside host elements matching .bar */ .bar::shadow(.foo) { ... } } The ::shadow() pseudo-selector should also support the :root pseudo-selector to enable children selectors, for example: @host { /* match .foo shadowDOM children inside host elements matching .bar */ .bar::shadow(:root > .foo) { ... } } 87700 1 tasak 2013-05-15 02:26:32 +0000 I would like to confirm how ::shadow works. (In reply to comment #0) > @host { > /* match .foo shadowDOM children inside host elements matching .bar */ > .bar::shadow(:root > .foo) { > ... > } > } Since "match .foo shadowDOM children inside host elements matching .bar", ".bar::shadow(:root > .foo)" doesn't match a host element whose class is bar and whose shadow root has any direct child whose class is foo. So, if we write the followings, what elements should the followings match? @host { .bar::shadow(:root > .foo) > div { .... } .bar::shadow(:root > .foo) div { .... } } Are the above rules the same as the followings? @host { .bar::shadow(:root > .foo > div) { .... } .bar::shadow(:root > .foo div) { .... } } Or should we disallow the above rules? 87840 2 sorvell 2013-05-17 23:05:33 +0000 (In reply to comment #1) > Since "match .foo shadowDOM children inside host elements matching .bar", > ".bar::shadow(:root > .foo)" doesn't match a host element whose class is bar > and whose shadow root has any direct child whose class is foo. I'm not sure I follow this. Are you just saying that we're changing the @host rule from always matching the host element to matching other elements? If so, then yes, that's the goal of adding ::shadow, to be able to style shadowDOM elements based on the host's selectors. > So, if we write the followings, what elements should the followings match? > > @host { > .bar::shadow(:root > .foo) > div { > .... > } > .bar::shadow(:root > .foo) div { > .... > } > } > > Are the above rules the same as the followings? > > @host { > .bar::shadow(:root > .foo > div) { > .... > } > .bar::shadow(:root > .foo div) { > .... > } > } > > Or should we disallow the above rules? Yes, the above rules (first set) don't make sense. I vote to disallow that. This points out that the syntax here is awkward. 87911 3 tasak 2013-05-20 08:07:11 +0000 Thank you for replying. (In reply to comment #2) > I'm not sure I follow this. Are you just saying that we're changing the > @host rule from always matching the host element to matching other elements? > If so, then yes, that's the goal of adding ::shadow, to be able to style > shadowDOM elements based on the host's selectors. I just confirm ::shadow's situation. When we write something like "div:not(...)", we want to get "div" (:not(...) is just specifying div's condition. So "..." part is just a sub-selector). div::shadow(...) is different from the above. We don't want to get "div". We need to look into "..." part from "div". > Yes, the above rules (first set) don't make sense. I vote to disallow that. That makes sense. I would like to ask one more. I found another concerns, i.e. multiple pseudo elements. @host { // unknown pseudo + ::shadow .bar::x-unknown-pseudo::shadow(.foo) { ... } // multiple ::shadow .bar::shadow(.foo)::shadow(.foobar) { ... } // ::shadow + ::distributed .bar::shadow(.foobar)::distributed(.foo) { ... } } We should support all the above cases, support some of the above or disallow all the above? 87924 4 tasak 2013-05-20 15:10:48 +0000 (In reply to comment #3) I'm sorry. I found http://www.w3.org/TR/2012/WD-selectors4-20120823/#pseudo-elements Only one pseudo-element may appear per selector, and only if the subject of the selector is the last compound selector in the selector. If present the pseudo-element must appear after the compound selector that represents the subjects of the selector. So my examples are disallowed, because mutiple pseudo elements are specified. (I don't know the future pseudo-elements and CSS selector... c.f. A future version of this specification may allow multiple pseudo-elements per selector.) The spec also says: "Syntactically, a pseudo-element may be followed by any combination of the user action pseudo-classes. Whether these pseudo-classes can match on the pseudo-element depends on the pseudo-class and pseudo-element”s definition: unless otherwise-specified, none of these pseudo-classes will match on the pseudo-element." So we probably need to define what pseudo-classes can work with ::shadow. 90892 5 dglazkov 2013-07-17 22:12:35 +0000 *** This bug has been marked as a duplicate of bug 20957 ***