This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
What is the meaning of <style scoped> @host { ... } </style> in a shadow tree? It would be useful to lift the scoping of the rules to content distributed into the scope, for example: <div id="news"> <div class="breaking">Zombie Apocalypse Upon Us</div> <div class="human-interest">Kitten Saved from Tree</div> </div> Assuming #news has this Shadow DOM: <div> <style scoped> @host { div:before { content: "!!!"; } } </style> <content select=".breaking"></content> </div> <div> <style scoped> @host { div:after { content: "- More at 11." } } </style> <content></content> </div> By lifting the scoping of the style to content distributed into the scope, we would have this rendering: !!!Zombie Apocalypse Upon Us Kitten Saved from Tree - More at 11. As it is, it is unclear what the interpretation of @host in <style scoped> should be, for example this: Zombie Apocalypse Upon Us Kitten Saved from Tree (ie nothing applied because the host is outside the scope) or this: !!!Zombie Apocalypse Upon Us - More at 11. !!!Kitten Saved - More at 11. (ie applied to @host, but the scope is not lifted.) Not lifting the scope means that the style author has to duplicate their content selectors in the host rule, which will have affect specificity and means changing a content selector will also require updating stylesheets. By lifting the scoping over distributed content, then only the content selector needs to change. Full credit goes to Takashi Sakamoto for discovering this -- I am just scribe.
(In reply to comment #0) > What is the meaning of > > <style scoped> > @host { ... } > </style> > > in a shadow tree? Right now, it's not mentioned that "scoped" affects anything, so I assumed that it's clear that @host only affects the shadow host, regardless of the value. > > It would be useful to lift the scoping of the rules to content distributed into > the scope, for example: > > <div id="news"> > <div class="breaking">Zombie Apocalypse Upon Us</div> > <div class="human-interest">Kitten Saved from Tree</div> > </div> > > Assuming #news has this Shadow DOM: > > <div> > <style scoped> > @host { div:before { content: "!!!"; } } This is not the way @host is spec'd now. You can't put selectors inside. You can only put properties: @host { color: red; } > As it is, it is unclear what the interpretation of @host in <style scoped> > should be, for example this: Does my explanation make it more clear? To style contents, distributed to insertion points, you have only one method: /select/ reference combinator.
(In reply to comment #1) > To style contents, distributed to insertion points, you have only one method: > /select/ reference combinator. The spec contains this language: "CSS rules declared in a shadow DOM subtree must not apply in the document tree" I think an exception needs to be carved out for @host rules and rules using /select/. There is a quasi-exception in the form of a conflicting requirement for @host: "The declarations in the @host @-rule must be applied to the shadow host of the shadow DOM subtree in which the style is specified." But I think the first requirement needs to be articulated to mention @host and /select/. It would be nice if the CSS application algorithm could specify all of this too.
(In reply to comment #1) > (In reply to comment #0) > > What is the meaning of > > > > <style scoped> > > @host { ... } > > </style> > > > > in a shadow tree? > > Right now, it's not mentioned that "scoped" affects anything, so I assumed that > it's clear that @host only affects the shadow host, regardless of the value. I would like to ask how to find matched scoped styles which contain @host rules. For example, there is some HTML document like: <div id="host"> <div id="child-a"></div> <div id="child-b"></div> </div> and a shadow root (attached to the div whose id is "host") is <div> <style scoped> @host { color: red } </style> <content select=":first-child"></content> </div> <div> <style scoped> @host { color: blue } </style> <content></content> </div> We have to go up a DOM tree to find matched styles. So to find child-a or child-b's style, we will go up the following tree: host------------------#shadow-root... | +----child-a | +----child-b If we have no @host rules, it is ok to look at child-a and host node to find child-a's matched styles. However, if the above "scoped" works, I think, we have to traverse in the following way: host | +----#shadow-root | +-----div (has scoped @host rule) | +----- child-a (color: red) Talking about child-b, host | +----#shadow-root | +-----div (has scoped @host rule) | +----- child-b (color: blue) If we cannot make @host rules "scoped", host (color: blue) | +----child-a host (color: blue) | +----child-b (in this case, we cannot change the color of child-b.) I'm not sure which is better for web developers. However according to an idea of @host rules, i.e. web developers can change styles of host nodes, I think, they want to change styles per <content> (or <shadow>). Best regards, Takashi Sakamoto
(In reply to comment #3) > I would like to ask how to find matched scoped styles which contain @host > rules. Per comment #1 it sounds like @host ignores the scoped attribute ("@host only affects the shadow host, regardless of the value") so in your example the host's color property would be blue. The color would not depend on the scope. It might be useful to specify the order of stylesheets in Shadow DOM for the purpose of the cascade. Presumably stylesheets in younger shadow roots override stylesheets in older shadow roots.
(In reply to comment #4) > (In reply to comment #3) > > I would like to ask how to find matched scoped styles which contain @host > > rules. > > Per comment #1 it sounds like @host ignores the scoped attribute ("@host only > affects the shadow host, regardless of the value") so in your example the > host's color property would be blue. The color would not depend on the scope. > > It might be useful to specify the order of stylesheets in Shadow DOM for the > purpose of the cascade. Presumably stylesheets in younger shadow roots override > stylesheets in older shadow roots. Thank you for explanation. I will update my draft design doc according to this. Best regards, Takashi Sakamoto
Split off specifying the order into bug 18418, closing this bug.