:host(use) > symbol in a UA sheet does nothing.

[emilio]

https://svgwg.org/svg2-draft/styling.html#UAStyleSheet says that the following rule needs to be in a UA sheet:

:host(use) > symbol {
  display: inline !important;
}

That rule does nothing though, since :host only works when evaluated in the context of a shadow tree per:

https://drafts.csswg.org/css-scoping/#host-selector
https://drafts.csswg.org/css-scoping/#in-the-context-of-a-shadow-tree

[AmeliaBR]

The user agent stylesheet would also be incorporated into the context of the shadow tree, so I don't see the problem?

[emilio]

UA sheets are not matched in Shadow tree context, at least in Gecko. I wouldn't expect a UA sheet (nor a user sheet) to match :host, for example, though maybe other impls differ?

[svgeesus]

What is this rule trying to accomplish? I suspect it is trying to say that the symbol is always displayed, even if some ancestor in the place where the symbol is defined has display: none. If so, there are probably better ways to say so.

[css-meeting-bot]

The SVG Working Group just discussed `:host(use) > symbol` in a UA sheet does nothing.

The full IRC log of that discussion

<AmeliaBR> Topic: `:host(use) > symbol` in a UA sheet does nothing
<AmeliaBR> github: https://github.com//issues/502
<AmeliaBR> Amelia: A symbol is defined to be display: none by default. However, when it is cloned into a use element shadow tree (as the directly referenced element on the <use>), then it needs to display.
<AmeliaBR> ... Issue brought up has to do about how stylesheets match with shadow DOM content.
<AmeliaBR> Probably needs to change to `:shadow-root > symbol`, but I don't know if such a pseudoclass exists.
<AmeliaBR> ... because the symbol isn't actually a "child" of the use element, so can't use the `>` combinator.
<AmeliaBR> Chris: So what can we do?
<AmeliaBR> Amelia: One option is to go back to defining this in prose, like in SVG 1.1
<AmeliaBR> Chris: Don't want to define anything using shadow-piercing selectors, since those are still very unstable specifications.
<AmeliaBR> Amelia: Should be able to avoid shadow-piercing, by just defining the rule to apply within the shadow dom, with a regular `:root > symbol` selector.
<AmeliaBR> ... it means an extra user-agent stylesheet that only applies in use-element shadow trees.
<AmeliaBR> Chris: OK, we can propose that & see what feedback we get.
<AmeliaBR> Proposed Resolution: Handle user-agent rules for `symbol` with a special stylesheet & no shadow-piercing
<AmeliaBR> Resolution: Handle user-agent rules for `symbol` with a special stylesheet & no shadow-piercing selectors

[AmeliaBR]

So, to recap: I was using the :host() selector incorrectly; it matches the actual host element in the light tree, not the shadow root node created for the host.

Since there isn't a designated selector that only matches shadow roots (let alone shadow roots with a specific host type) we have to use the :root selector and then clarify that the rule only applies within use-element shadow trees.

There's nothing unusual about shadow trees having their own stylesheets. And they always have the usual user-agent stylesheets. I don't think there is any other explicit case of requiring a user-agent stylesheet that is unique to a particular type of shadow tree. But there are many cases of HTML replaced elements that probably work out that way. And since we've also agreed that use-element shadow trees are closed (#396), user agents would have flexibility about how they actually implement it.

[tabatkins]

UA sheets are not matched in Shadow tree context, at least in Gecko. I wouldn't expect a UA sheet (nor a user sheet) to match :host, for example, though maybe other impls differ?

UA stylesheets definitely are matched in shadow contexts; if they weren't, then everything in a shadow would become unstyled inline elements.

(Hmm, don't know if this is actually written anywhere. The fact that UA stylesheets get applied to shadow trees is definitely required in practice; it matching "in a shadow context" falls out of the definition of matching against a shadow tree.)

So, to recap: I was using the :host() selector incorrectly; it matches the actual host element in the light tree, not the shadow root node created for the host.

No, you were using it correctly; in a shadow context, the host element is treated as if it were the root of the shadow tree. :host(use) > symbol will match any "top-level" symbol element in a shadow tree, as long as the host element is a use.

[AmeliaBR]

:host(use) > symbol will match any "top-level" symbol element in a shadow tree, as long as the host element is a use.

@tabatkins Are you able to add text & maybe an example to CSS Scoping to that effect? Because it's not clear as I read the spec right now.

From CSS Scoping:

The :host pseudo-class, when evaluated in the context of a shadow tree, matches the shadow tree’s shadow host.

From DOM, emphasis added:

an associated host (null or an element in a different node tree).

So if host(use) is selecting the host element in the light(er) tree, then the symbol is not a direct child, unless you've changed how the > combinator works.

It would certainly make this spec easier if it did work that way, but reading the specs again, I'm not confident that's defined anywhere.

[tabatkins]

That is indeed already specified in the spec, in section 3.2.2:

For the purpose of Selectors, a shadow host also appears in its shadow tree, with the contents of the shadow tree treated as its children. (In other words, the shadow host is treated as replacing the shadow root node.)

[AmeliaBR]

That is indeed already specified in the spec, in section 3.2.2:

Ok, then. So I'll consider this issue closed and the changes resolved to on the telecon are unnecessary.

But it still wouldn't hurt to have a specific example in scoping. Could be a single sentence like: "For example, :host > :first-child selects the first child of the shadow root node."

[tabatkins]

Good point, I'll add one.