This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider this situation: <style> p { color: green; } <div id="foo"> <style scoped> p { color: red; } </style> </div> <script> var root = document.querySelector('#foo').createShadowRoot(); root.innerHTML = "<content></content><p>What color am I?</p> </script> My intuition tells me that we should simply disallow these shenanigans, and the color of p is green. In other words, a scoped style that is a child of a shadow host does not do anything.
Tab, WDYT?
(In reply to comment #0) > Consider this situation: > > <style> p { color: green; } > <div id="foo"> > <style scoped> > p { color: red; } > </style> > </div> > <script> > var root = document.querySelector('#foo').createShadowRoot(); > root.innerHTML = "<content></content><p>What color am I?</p> > </script> > > My intuition tells me that we should simply disallow these shenanigans, and > the color of p is green. In other words, a scoped style that is a child of a > shadow host does not do anything. What's the effect of a scoped stylesheet in the shadow root itself? That still works, right? Have we fully clarified whether <content> is *replaced* by its matched light DOM, or just *filled* with it (and then doesn't render, via magic like "box:contents")?
(In reply to comment #2) > (In reply to comment #0) > > Consider this situation: > > > > <style> p { color: green; } > > <div id="foo"> > > <style scoped> > > p { color: red; } > > </style> > > </div> > > <script> > > var root = document.querySelector('#foo').createShadowRoot(); > > root.innerHTML = "<content></content><p>What color am I?</p> > > </script> > > > > My intuition tells me that we should simply disallow these shenanigans, and > > the color of p is green. In other words, a scoped style that is a child of a > > shadow host does not do anything. > > What's the effect of a scoped stylesheet in the shadow root itself? That > still works, right? Depends on what we deem the effect of "shadowing a DOM tree" to be to styling. What would be the most logical thing to do here from CSS perspecive? > Have we fully clarified whether <content> is *replaced* by its matched light > DOM, or just *filled* with it (and then doesn't render, via magic like > "box:contents")? Nope, not yet. If it helps to sway in either direction, this is all flexible.
Actually, I think I've been barking up the wrong tree anyway. The entire point of <style scoped> is solely to make it easier and less error-prone to target only a particular element and its descendants. You should be able to replace <style scoped>:scope p</style> with <style>#parent p</style> without any change in meaning or targeted elements. So, same thing here. The <style scoped> is scoped to the host element, and naturally applies its selectors on the light dom side, since that's where it lives. It shouldn't target anything in the shadow dom unless you let selectors through. (Where it gets distributed into the shadow dom shouldn't make a difference - it's scoped to its original parent.)
(In reply to comment #4) > Actually, I think I've been barking up the wrong tree anyway. Okay. So the color of p is red, but only because it is inherited from div#foo. Right?
(In reply to comment #5) > (In reply to comment #4) > > Actually, I think I've been barking up the wrong tree anyway. > > Okay. So the color of p is red, but only because it is inherited from > div#foo. Right? Lol, sorry -- typing faster than thinking. No, it will be green, because #foo is a div, not a p.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Actually, I think I've been barking up the wrong tree anyway. > > > > Okay. So the color of p is red, but only because it is inherited from > > div#foo. Right? > > Lol, sorry -- typing faster than thinking. No, it will be green, because > #foo is a div, not a p. In your example, it'll be black, because you aren't letting selectors through, and the top-level <style> is just targeting <p>s, so there's nothing there to style the shadow <p>. ^_^
(In reply to comment #7) > In your example, it'll be black, because you aren't letting selectors > through, and the top-level <style> is just targeting <p>s, so there's > nothing there to style the shadow <p>. ^_^ jeseus.
I am thinking that we can close this for a moment so that we can focus higher priority issues because, in practical, blink has stopped the support for <style scoped>. Please feel free to re-open this if we need to think again how <style scoped> interacts with shadow trees.