20957 2013-02-12 00:00:03 +0000 [Shadow]: Styling elements in shadow trees based on host element 2014-04-24 00:55:21 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 22788 23062 1 dglazkov hayato dominicc hayato jackalmage sorvell tasak public-webapps-bugzilla oldest_to_newest 82933 0 dglazkov 2013-02-12 00:00:03 +0000 From Tab: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0353.html --- It's possible to style a host element from within the shadow's stylesheet, and use the host's own qualities, by using the @host rule. It's also possible to style the shadow elements themselves, in their own self-contained universe. What doesn't seem possible is to use the host element's qualities (such as tagname, attributes, class, etc.) to style elements in the shadow tree. Currently, the only way to even *refer* to the host element from within a shadow-tree stylesheet is by using the @host rule, which contains style rules. The selectors there are limited to only targetting the host element itself. This came up in a hallway discussion about dropping resetStyleInheritance in favor of CSS's new 'all' property <http://dev.w3.org/csswg/css3-cascade/#all-shorthand>. Doing so would be fine, technically - the property accomplishes the same thing as the attribute - but it falls down on usability. We want to *default* to having an inheritance shield, and let the author lower it if they choose, but you can't "unset" a property; if we start with "all: default" set, the author can't remove the declaration and lower the shield. If we kept the attribute and simply implemented it as the 'all' property using an attribute selector, though, it all works out. However, you can't do that currently, as far as I can tell. This ability seems to be potentially useful beyond the use-case above, just for a lot of author-facing design problems. The problem seems to stem from the fact that the host element is "owned" by both the outer page and the component author. We currently work around that dual ownership by using @host to let you target the element directly. However, this is an incomplete workaround. I have a possible solution, though I'm not sure I like it: expose a ::shadow(<selector>) pseudo-element that is only usable inside of @host. This'll solve the problem, but it seems inelegant. 90886 1 dglazkov 2013-07-17 21:52:12 +0000 I think we can do this now, based on the latest proposal of matching host inside of the shadow tree. 90893 2 dglazkov 2013-07-17 22:12:35 +0000 *** Bug 21390 has been marked as a duplicate of this bug. *** 104306 3 hayato 2014-04-24 00:55:21 +0000 Let me close this bug. I believe CSS scoping spec [1] has already addressed this issue. [1]: http://dev.w3.org/csswg/css-scoping/