:host-context(my-el) inside a <my-el> custom element matches even for a standalone <my-el>

[franktopel]

What is the issue with the HTML Standard?

From what I've researched so far, there currently is no way in CSS to detect if my component is nested inside another instance of the same component.

See this codepen: https://codepen.io/connexo/pen/xbxVyMY

Code:

const css = `
:host {
  color: green; 
}
:host-context(my-el) {
  color: orange;
}
`;
const sheet = new CSSStyleSheet;
sheet.replaceSync(css);

customElements.define('my-el', class extends HTMLElement {
  #slotEl = document.createElement('slot');
  constructor() {
    super().attachShadow({ mode: 'open' }).adoptedStyleSheets = [sheet];
    this.shadowRoot.append(this.#slotEl);
  } 
});

<my-el>
  Outer my-el, this text should be green.
  <my-el>Inner my-el, this text should be orange.</my-el>
</my-el>

<br><br>

<my-el>Standalone</my-el>

Of course there is workarounds for this in JavaScript, but imo I shouldn't be forced into using JavaScript for a task that I understand is clearly the job of CSS.

Other than being able to re-use the same CSS for different tag names and differentiating, I don't see a reasonable use-case for :host-context() to ever match the :host itself.

I've also tried workarounds in CSS, none of which worked:

:host(:host-context(my-el)) { /* never applied */ }

:host-context(my-el):not(:host) { /* never applied */ }

What's the rationale behind the :host-context() being able to match itself? And what could be done to resolve the very common nesting use-case on the CSS side for this, from inside the shadowDOM?

Using regular document.adoptedStyleSheet's CSS for this is no option, since the nesting case could also occur inside a shadow root of another custom element.

I am raising this here in WhatWG/html because I'm assuming the CSS part of the custom element specification is rather located here than over at the CSSWG. If that assumption is wrong, please point me to where it belongs.

[tabatkins]

The definitions of these pseudo-classes does live over in CSS, in CSS Scoping.

This is working as intended. :host-context() is meant to allow your shadow to respond to a theming class or attribute somewhere outside of itself, and intentionally includes both "on the host" and "on the host's ancestors". Otherwise, the most common case (that we purposely designed towards) would have to always be written :host(.dark-theme), :host-context(.dark-theme) to catch both spots that a dark theme could potentially be indicated.

Could you elaborate more on what use-case you're trying to achieve here? The example given is too artifical for me to tell why you're wanting this.

---

I've also tried workarounds in CSS, none of which worked:

:host(:host-context(my-el)) { /* never applied */ }

:host-context(my-el):not(:host) { /* never applied */ }

Correct, neither of these should work.

In the first, the :host-context(my-el) is evaluated in the outer context, where the host element is no longer the host of the tree it finds itself in, so it won't match.

In the second, :host-context() matches the host element, and :not(:host) matches everything but the host element, so the selector can't match anything.

[franktopel]

My use case shouldn't be too relevant here. The fact that I cannot achieve this goal with CSS alone to me is a clear hint of missing functionality.

On top of that, the way :host-context() may have its intended uses, but for me came as a complete surprise, despite developing full time web components since early 2018, continously and only, up until today. The same kind of surprise was that this.closest(this.tagName) === this is always true, but that has an easy workaround without the need to resort to a different technology: this.parentElement?.closest(this.tagName) === this.

The use-case that you pointed out, by the way, does have an alternative solution, even if less convenient, within CSS. For the nesting use case, there simply is no workable solution in CSS.

I'd like to see an addition (e.g. :host-outer-context(selector)) to fix this. It doesn't feel complete that one is able to detect any ancestor context, with the exception of your own tag name.

[franktopel]

@tabatkins P.S.: If there is an easy way to send this issue where it belongs, feel free to do so.

[tabatkins]

Use-cases are completely relevant. Without knowing what you're trying to do, we can't judge how common such a need would be in general, and so can't judge whether it would be sufficiently useful to justify adding a new feature. There are, after all, a myriad of things you can't do with CSS alone, and most of them we leave unsolved because they're relatively small problems and don't justify their cost.

It doesn't feel complete that one is able to detect any ancestor context, with the exception of your own tag name.

That is not what is happening here. The limitation is that you can't write a selector that matches only on ancestors of your host but not your host itself. Whether that selector is matching on tag name, class, attribute, or something else doesn't affect this; all those cases can't distinguish between the host element and its ancestors.

This was an intentional choice to hide aspects of the outer page from the shadow tree, much like how most aspects of the shadow tree are hidden from the outer page. We almost failed to get :host-context() at all, but I was able to sell it on the use-case of "detecting theming classes". Exposing more structure (such as whether something matches on the host vs an ancestor) would be a bit of a hard sell. At that point more questions arise, like whether you should be allowed to query more of the structure and include combinators in the selector argument.

[franktopel]

Use-cases are completely relevant. Without knowing what you're trying to do, we can't judge how common such a need would be in general, and so can't judge whether it would be sufficiently useful to justify adding a new feature. There are, after all, a myriad of things you can't do with CSS alone, and most of them we leave unsolved because they're relatively small problems and don't justify their cost.

This clearly isn't a cost issue. It is a design decision that has been made, and which sacrifices the nesting case for a QoL-improvement on something that could also be achieved otherwise.

It doesn't feel complete that one is able to detect any ancestor context, with the exception of your own tag name.

That is not what is happening here. The limitation is that you can't write a selector that matches only on ancestors of your host but not your host itself. Whether that selector is matching on tag name, class, attribute, or something else doesn't affect this; all those cases can't distinguish between the host element and its ancestors.

Thanks for putting even more flesh on the bone here. Why should we not be able to detect the outer context?

This was an intentional choice to hide aspects of the outer page from the shadow tree, much like how most aspects of the shadow tree are hidden from the outer page. We almost failed to get :host-context() at all, but I was able to sell it on the use-case of "detecting theming classes". Exposing more structure (such as whether something matches on the host vs an ancestor) would be a bit of a hard sell.

"Context" for me transports "where an element lives". Since :host affects the shadow-hosting element, :host-context() fuels the (false) assumption that it is about just that. And at least for tag names other than the element's own tag name that happens to be just exactly what it does, further fuelling the false assumption its name creates. I get that we cannot change how :host-context() behaves now; but it would be really handy to have something existing that fulfills the expectations created by :host-context(), like e.g. a :host-outer-context().

To elaborate on my use-case, even though this is a much smaller part of the motivation for me to come here and raise an issue: I have a component that I want to be able to be freely nestable. If used standalone, it comes with fixed definitions of such things as font-size: 22px; (ignore the fact it's px); if it's nested inside another one of its kind, I want those properties to inherit their values.

[tabatkins]

This clearly isn't a cost issue. It just a design decision that has been made, and which sacrifices the nesting case for a QoL-improvement on something that could also be achieved otherwise.

I recommend not making assumptions about what is "clearly" true when you don't have sufficient context on the details. You are wrong in this case - caring more about structure carries some potential matching costs, and adding a new feature definitely carries costs.

Why should we not be able to detect the outer context?

That isn't the right question. We must justify adding features, not justify failing to add them. Like I said, there was a push originally to only have :host(), which would have required putting things like theming classes directly on every component. The use-cases behind having theming classes higher in the tree were sufficiently persuasive that we were able to get :host-context() in.

You now ask for a further feature - being able to detect where some selector matches outside the tree, at least to some extent. That means a component can now act differently based on more details of its surroundings, which is something we intentionally didn't allow in the past.

"Context" for me transports "where an element lives".

That's a valid interpretation of the word "context", sure, but it's not what is meant by this usage of the word "context". It was intentional that we hide the structure of the outside tree, and just let some notion of "theming" be detectable.