[specificity] Specifity of ::slotted() is greater than :host

[gavinmcfarland]

If you declare styles inside a component which use the :slotted() selector then styles applied by any child components which are uses inside that component cannot be overridden using :host.

/* Parent custom element */
:slotted(*) {
    color: green;
}

/* Child custom element */
:host {
    color: red;
}

I would expect the child custom element's text to be red, but it is in fact green.

http://jsbin.com/cecuxad/edit?html,console,output

Is there anything in the spec that covers this behaviour?

[emilio]

Unless I'm missing something this is working as expected. The children would only be red because of inheritance, but there's a rule specifying its color to green.

[emilio]

i.e., this doesn't have to do anything with specificity at all.

[tabatkins]

Yes, this particular issue is purely a result of the way the cascade handles inheritance vs direct application; it has nothing to do with specificity at all, since there aren't any clashing rules.

[gavinmcfarland]

Sorry it's not clear from the replies, is it an issue or not? If it's not specificity, is it just a downfall of the "direct application" you mention?

If it were standard html and css it would be red wouldn't it?

<style>
.host1 * {
    color: green;
}
.host2 {
    color: red;
}
</style>

<div class="host1">
    <div>green</div>
    <div class="host2">red</div>
</div>

This undesired behaviour causes a lot of problems when designing composable elements as the nested custom element has no way of overriding the rules governed by the parent custom element (unless there is a technique I don't know about?).

[tabatkins]

In your original example, the green and the red aren't being specified on the same element, so there's no specificity issue. Instead, you're setting the color on :host and relying on inheritance to propagate that downwards, but inheritance always loses to directly styling an element (which ::slotted(*) does), no matter what selector it comes from.

In your latest example, the two declarations are specifying the same property on a single element - "color: green" is being specified on the host2 element via the .host1 * selector, and "color: red" via the .host2 selector. Since there are competing declarations, we rely on specificity to sort things out - in this case, both selectors have specificity [0,1,0] (because the universal selector doesn't add any specificity), and so we fall back to source ordering, so "red" wins.

[gavinmcfarland]

In your original example, the green and the red aren't being specified on the same element, so there's no specificity issue.

Are they not being specified on the same element?

/* my-parent.html */
:slotted(*) {
    color: green;
}

targets the same element that

/* my-child.html */
:host {
    color: red;
}

does?

<my-parent>
    <my-child></my-child>
</my-parent>

The child element is the slotted element of the parent.

Perhaps it's confusing things because I am using an example property which is inherited? This would still be an issue if it was using margin for example.

[emilio]

Oh, I see what you mean. host rules are indeed applied before slotted rules indeed, even though !important rules are applied in the reverse order (except in FF where we still don't implement that last bit, though we don't ship Shadow DOM).

[emilio]

It's still not about specificity itself though.

[gavinmcfarland]

Ok it might not be about specificity, but to a layman I have no other way of describing it.

How do we take this further?

Is it a spec issue or a technical issue?

[tabatkins]

Oh! I didn't realize there was a parent/child relationship going on here, I gotcha now. I should read more. (Cases like this are often confusing to explain; it helps to provide a markup example with shadow trees drawn in.)

(Yeah, it's technically not specificity, but that's close enough to work. Technically it's the "Shadow Tree" cascade step; specificity is another cascade step.)

So yeah, the ::slotted(*) and :host rules come from different trees, and the ::slotted(*) tree is earlier in the tree order (as it's a parent), so it wins. This is meant to address the usage pattern that components can set up their defaults via normal styling, then users of the components can reach in and override easily; components can guard styles that must be a particular value with !important, which wins over outside rules.

So yeah, the element ends up green, and that's intended behavior.

In general, styling of the host element is a coordination between the shadow tree and the outside page. ::slotted() isn't relevant to this example; you could just as easily have had:

<style>
.foo { color: green; }
</style>
<x-foo class=foo>
 <::shadow>
  <style>
  :host { color: red; }
  </style>
 </::shadow>
</x-foo>

In this case, the element ends up with color: green, again because the "green" rule comes from an "earlier" tree in the tree-of-trees than the "red" rule.

[gavinmcfarland]

I did provide a jsbin example but perhaps I should have been more explicit in my explanation.

Thanks very much for taking the time to explain that. I won't pretend to understand it all but I get the gist of it. I don't agree with the approach of using !important one should allow nested components to supersede styling from up the tree, but not to prevent it entirely.

Coming from conventional html and css and my inferior experience with custom elements and the shadow dom, it doesn't seem natural to me, but I appreciate I'm probably not smart enough to understand the reasons why.

The best method I can find is to use a custom css property. This allows me to let nested custom elements override styles from outside but still allow me override the styling of the component should I need to. It might be useful to someone else in my situation although I feel one shouldn't have to do this because it can complicate things depending on your project.

/* my-parent.html */
:slotted(*) {
    color: var(--color);
    --color: green;
}

/* my-child.html */
:host {
    color: var(--color);
   --color: red !important;
}