This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given an element with a stack of shadowRoot's, it's common to want to write styles in one shadowRoot that apply to sibling shadowRoots. Typically, if one creates an additional shadowRoot on an element and decides to include the older root via <shadow>, one wants to control how this older root is styled. Likewise, it's common to want to inherit styling from an older shadowRoot in a younger one. When styles are scoped to a specific shadowRoot, this is not possible. With the addition of the ^ combinator this becomes possible but requires a more complicated, cumbersome syntax for the common case (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23467). Instead, this should be the default behavior. Here's an example: <host> [SR1] <style> .foo { background: red; } </style> <div class="foo"></div> [SR2] <style> .foo { color: green; } </style> <div class="foo"></div> Both [SR1] .foo and [SR2] .foo should have green text with a red background.
This would also allow us to eliminate the [space] and > combinators to the right of :host. These combinators next to :host are confusing since one would think they match elements in the host's scope, but they in fact, match elements in the shadowRoot. For example, :host means match the host but :host > * means match children inside the host's *shadowRoot*. Instead, these combinators should match nothing when to the right of :host. The ^ combinators should be used for these types of selectors since it specifically jumps into a shadowRoot. 1. match an element in shadowRoot that matches .foo if a host matches .bar: * old: :host(.bar:host) .foo * new: :host(.bar:host) ^ .foo 2. match an element that's a .foo child of a shadowRoot if a host matches.bar: * old: :host(.bar:host) > .foo * new: :host(.bar:host) ^ :top > .foo The proposed selectors are non-trivial, but they avoid applying magical new behavior for the [space] and > combinators.
This means that component authors need to be really careful how they write their CSS and also of how they structure the markup inside their widgets. Previously you could do: <x-expander>'s ShadowRoot: <style> div { display: none; } .expanded { display: block } </style> <button>Expand me</button> <div> <content></content> </div> <script> // onclick of the button add "expanded" to the div. </script> but this component author has just prevented people from inheriting from his component because now they can't use <div> as it'll be display: none so they have to add even more CSS to undo this. It also means you need to be super careful not to collide with your superclass with class names so even though you can use the same id in both of them like #container and then this.$.container in polymer, you can't style them separately because the CSS ends up applying to both. This doesn't seem like a good change, it breaks the encapsulation in a way that now authors need to constantly be careful with what CSS they use.
(In reply to Elliott Sprehn from comment #2) >... > > It also means you need to be super careful not to collide with your > superclass with class names so even though you can use the same id in both > of them like #container and then this.$.container in polymer, you can't > style them separately because the CSS ends up applying to both. > It seems Polymer already has this issue, if you have an id conflict then this.$.container will always be the one from the youngest shadow root. So I can understand why allowing conflicts for div { display: none; } doesn't seem like an issue as Polymer already has an opinion that you just shouldn't do that. Previously CSS matched the same as querySelector() so if <style> in any ShadowRoot applies to all others on that element why doesn't shadowRoot.querySelector("div") return ones in all the other ShadowRoots? Or why doesn't root.getElementById("x") return things from the older shadow root like this.$ would? Can you give examples why you want DOM level encapsulation but no style encapsulation?
I generally think of the inheritance relationship as being non-encapsulating; as opposed to the composition relationship which relies on encapsulation. Polymer uses <shadow>/olderShadowRoot typically to implement inheritance relationships, so by the above it feels natural to remove style encapsulation. By the same token, we would probably favor loosening of the DOM encapsulation too, but I can't say right now what form that would take. However, here are (at least) two arguments against this ticket that I cannot dispute beyond the above. 1. It's awkward for the ShadowDOM machinery to share styles in this manner, and it lacks parallelism vs querySelector. 2. The notions of inheritance vs encapsulation as described above are certainly my opinion. I'm willing to concede this on those points if that's desirous. Last bit: If we kill this issue, I think we need a new (declarative) way to override styling on inherited shadow root. Is there already a syntax for that?
Is this feature request still valid? Can we close this?
Let me close this. I think this is obsolete one.