Bug 20957 - [Shadow]: Styling elements in shadow trees based on host element
Summary: [Shadow]: Styling elements in shadow trees based on host element
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
: 21390 (view as bug list)
Depends on: 22788
Blocks: 23062
  Show dependency treegraph
Reported: 2013-02-12 00:00 UTC by Dimitri Glazkov
Modified: 2014-04-24 00:55 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2013-02-12 00:00:03 UTC
From Tab:


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.
Comment 1 Dimitri Glazkov 2013-07-17 21:52:12 UTC
I think we can do this now, based on the latest proposal of matching host inside of the shadow tree.
Comment 2 Dimitri Glazkov 2013-07-17 22:12:35 UTC
*** Bug 21390 has been marked as a duplicate of this bug. ***
Comment 3 Hayato Ito 2014-04-24 00:55:21 UTC
Let me close this bug.
I believe CSS scoping spec [1] has already addressed this issue.

[1]: http://dev.w3.org/csswg/css-scoping/