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
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.
I think we can do this now, based on the latest proposal of matching host inside of the shadow tree.
*** Bug 21390 has been marked as a duplicate of this bug. ***
Let me close this bug.
I believe CSS scoping spec  has already addressed this issue.