Question: Why do we care about this case? Shouldn't Element.prototype.getRootNode cover this case as well?

Yeah this is critical, without it, any child Shadowdom component of Isolated loses it's styles (they're hoisted to Isolated, outside of the scope of the style shadow boundary, so it loses it's styling)

The use case would be Isolated parent, that has a Shadowdom child (with an emulated component projected into the Shadowdom component) - without this, the emulated styles would go to the Isolated (and need to go to the ShadowDom host)

Sorry, I don't think I'm following this. In my mind, the core logic here should be:

function determineStyleTargets(el: Element): ShadowRoot[] {
  for (const component of walkAncestorComponents(el)) { // Or use `getRootNode` I guess...
    if (usesIsolatedShadowDomEncapsulation(component)) {
      return [component.shadowRoot]; // Apply styles to this one root.
    } else if (usesStandardShadowDomEncapsulation(component)) {
      return allStandardShadowRoots; // Legacy behavior, apply to all legacy roots.
    } else {
      continue; // Move to next ancestor.
    }
  }

  return []; // Not in a shadow root, append to `doc.head`.
}

Is there some combination of IsolatedShadowDom and ShadowDom components for which that doesn't work?

I'm probably doing a terrible job of articulating why this is needed tbf as it's quite nuanced (to me at least)! Let me try and break down what I see as happening:

Priority 1 handles projected content (elements in light DOM that are direct children of shadow hosts), while Priority 2 handles elements that are actually inside shadow trees.

When determineStyleTargets gets called:

• An Emulated or None component needs to apply its styles
• The renderer calls applyStyles(element) where element is the component's host element
• Inside applyStyles, it calls this.styleScopeService.determineStyleTargets(element)

What Priority 1 and 2 are checking:
Priority 1: "Is this component a projected direct child of a shadow DOM component?"

Checks if element.parentElement is a shadow root host
This catches: <shadow-component><!-- ng-content --><emulated-component/></shadow-component>

Priority 2: "Is this component inside a shadow DOM tree?"

Checks if element.getRootNode() is a shadow root
This catches components that are deeper inside shadow trees

Projected content has a disconnect between:

Physical DOM location (what getRootNode() sees)
Rendering context (where styles need to be applied)
Priority 1 bridges this gap by checking the parent-child relationship in the light DOM to infer the correct shadow root context for style targeting.

Your suggestion doesn't work because:
It only works for elements that are physically inside shadow roots. It completely misses the projected content case where:

• Element physically exists in light DOM
• Element visually renders inside shadow DOM
• Styles need to target the visual context (shadow root), not the physical context (document)

Priority 1 is essential for content projection directly into an IsolatedShadow, because getRootNode() would return the document instead of the shadow root where styles actually need to be applied - your suggested getRootNode()-only approach fails for projected content because it targets the physical DOM location rather than the visual rendering context.

More visually, without the 2 conditions/priorities, this is the use case that breaks:

I don't think we could ship without allowing/fixing the projection into an isolated shadow component as that's a valid use case (I know in my app of ~10,000+ components we will have use cases where we have some very dumb ui component like a card/panel from our ui library using Isolated, but we want to project more complex app specific Emulated components inside of it) - so suspect we'd be opening a can of worms of support tickets without it

Sorry I think I'm still struggling with this. Maybe a Stackblitz demo of this use case would be helpful to demonstrate why this branch is needed?

It might just be my confused understanding, but there are a few aspects of this which stand out to me as smells:

1. Checks if element.parentElement is a shadow root host
   This catches: <shadow-component><!-- ng-content --><emulated-component/></shadow-component>

   Content projection may not be a direct child of the host though (ex. <shadow-component><div><!-- ng-content --><emulated-component /><!-- /ng-content --></div></shadow-component>), so I feel like element.parentElement is the wrong mechanism here. At minimum, you probably need to iterate through some framework-level data structures to find the parent component you're being projected into.

2. Priority 1 handles projected content (elements in light DOM that are direct children of shadow hosts)

   Angular doesn't use native <slot> for content projection though, so how do you end up with light DOM in an IsolatedShadowDom component? All the content should be in the shadow tree, right?

3. Element physically exists in light DOM
   Element visually renders inside shadow DOM
   Styles need to target the visual context (shadow root), not the physical context (document)

   If the element is in light DOM, don't you need to style that "physical context"? (document.head or an ancestor shadow root?) I would expect to not style the shadow root for content projected from light DOM.

4. Does this all matter right now if we disable content projection for IsolatedShadowDom as I suggested in another comment? Is this a problem we can solve if/when we get to content projection via native <slot>?

Sorry I think I'm still struggling with this. Maybe a Stackblitz demo of this use case would be helpful to demonstrate why this branch is needed?

It might just be my confused understanding, but there are a few aspects of this which stand out to me as smells:

1. Checks if element.parentElement is a shadow root host
   This catches: <shadow-component><!-- ng-content --><emulated-component/></shadow-component>

   Content projection may not be a direct child of the host though (ex. <shadow-component><div><!-- ng-content --><emulated-component /><!-- /ng-content --></div></shadow-component>), so I feel like element.parentElement is the wrong mechanism here. At minimum, you probably need to iterate through some framework-level data structures to find the parent component you're being projected into.

2. Priority 1 handles projected content (elements in light DOM that are direct children of shadow hosts)

   Angular doesn't use native <slot> for content projection though, so how do you end up with light DOM in an IsolatedShadowDom component? All the content should be in the shadow tree, right?

3. Element physically exists in light DOM
   Element visually renders inside shadow DOM
   Styles need to target the visual context (shadow root), not the physical context (document)

   If the element is in light DOM, don't you need to style that "physical context"? (document.head or an ancestor shadow root?) I would expect to not style the shadow root for content projected from light DOM.

4. Does this all matter right now if we disable content projection for IsolatedShadowDom as I suggested in another comment? Is this a problem we can solve if/when we get to content projection via native <slot>?

Hey @dgp1130 - Currently laid up with COVID atm so my brain isn't thinking straight, trying to rack my brains of how we could create a stackblitz where we'd be able to fiddle with a local version of the core/platform-browser packages so we can tweak the code and make sure the use cases work and then go from there ... any ideas?

@dgp1130 - nevermind, i remembered how to do it 😄 - I've created this stackblitz. You should be able to edit the two packages in the /angular folder. If you comment out that first priority check we were talking about, you'll be able to see what stops working without it.

I think if we didn't style projected content, we'd cause ourselves a headache, as that's a pretty common use case (i know i'll definitely use it with isolated)

I'll hold off addressing the other comments until you've had a chance to have a look and have a fiddle, then we're on the same page about what it's doing. I probably won't get a chance to look till the end of next week

Currently laid up with COVID atm

Oh no! Hope you feel better soon, take it easy and don't stress out about this too much.

Thanks for that Stackblitz, it really helps I lot. I see how the priority 1 snippet is load-bearing, but I'm not convinced it's the right solution.

Firstly, as I mentioned, you can content project into a nested element, meaning checking the direct parent of the component is not sufficient. The example breaks if you just do:

<isolated-shadow-dom-component>
  <div>
    <button-component />
  </div>
</isolated-shadow-dom-component>

Secondly, I suspect there's a timing bug here. If I call (<button-component>).getRootNode() after rendering, I correctly get the expected shadow root. But if I breakpoint during determineStyleTargets and call (<button-component>).getRootNode(), I get document. Looking at the DOM, it seems that <button-component> is initially rendered in light DOM before somehow being moved into the shadow root.

I'm not very familiar with how content projection works under the hood, so this is a learning experience for me as well, but AFAICT from looking at the generated instructions and breakpointing around, I see that the main component includes:

function App_Template() {
  // ...
  \u0275\u0275elementStart(9, "isolated-shadow-dom-component")(10, "div");
  \u0275\u0275element(11, "button-component");
  \u0275\u0275elementEnd()();
  // ...
}

This appears to render <isolated-shadow-dom-component><div><button-component></button-component></div></isolated-shadow-dom-component> (all in light DOM) and is triggered here. Afterwards, we render component children to expand <isolated-shadow-dom-component> itself. This executes its template:

function ShadowDomComponent_Template(rf, ctx) {
  \u0275\u0275projectionDef();
  \u0275\u0275text(0, "Projected content:\n");
  \u0275\u0275domElementStart(1, "h4");
  \u0275\u0275text(2, "This will be green (from global styles)");
  \u0275\u0275domElementEnd();
  \u0275\u0275projection(3);
},

That last \u0275\u0275projection(3); call appears to move the element into the shadow root to its final position.

I feel like the fundamental issue here is that we're attempting to apply styles based on an intermediate state of the DOM. Ideally, we would render the element initially within the shadow root so it is always in a correct position, though that seems complicated from a timing perspective, since the parent element performing the projection renders before the child component has rendered the container element it will ultimately be projected into. I suspect the easier solution is to change the timing of when we apply styles to happen after the full component is fully rendered into its final position, then we could probably get rid of this "priority 1" case and .getRootNode() should return the desired ShadowRoot 100% of the time.

Third point is that I'm still not convinced content projection into a shadow root is a good idea in general or that we should propagate that design decision into IsolatedShadowRoot. In conversation with @jelbourn, it seems that you can apparently use native <slot> in the framework today. Our current thinking is that it's actually better to disable <ng-content> altogether for IsolatedShadowDom and point users are native <slot> instead. There's definitely a conceptual gap between those two concepts and this is definitely a non-trivial breaking change between ViewEncapsulation.ShadowDom and ViewEncapsulation.IsolatedShadowDom, but should leave us in a position closer to the web standard. From a styling perspective, this should make our job easier, as projected content will always be in the light DOM of its target component, so element.getRootNode() should return the correct value (once we figure out the timing issue above). Actually, I'd be curious if this fixes the timing issue because we wouldn't go through \u0275\u0275projection at all. None or Emulated components also won't leak their styles into shadow roots they happen to be projected into, which provides better isolation.

Does all that sound reasonable? Am I understanding the issue "priority 1" was supposed to address?

@dgp1130 - i think i'm with you

I've taken a stab at implementing this, stackblitz here

It's meant a few changes to a couple of packages which are hard to see from the compiled code, but essentially it was a change in projection.ts to the ɵɵprojectionDef function (this throws the console error)

And a change to handler.ts in compiler-cli to give us the nice dialog/compilation style error

Slot works, ng-content now throws an error

The other thing i've done is refactored the isolated_style_scope service to get rid of that priority check now we're using only slot as you suggested, and to use a load of framework helper functions i stumbled across in core (lview stuff essentially, namely the getLContext unwrapRNode HOST and PARENT)

I've not looked at if you start trying to project content inside a component that is in turn projected into isolated, as that's a rabbit hole to go down, maybe something we can add later (or someone from the team who is a lot more knowledgeable of the framework than I! 😆 )

Bug: Won't this throw for standard ViewEncapsulation.ShadowDom? I think we need to maintain the existing behavior and only throw for IsolatedShadowDom.

@dgp1130 - maybe i'm misremembering, but standard Shadowdom doesn't work in SSR either, right? Which is what this would catch. I could put in a condition to only throw for Isolated, but i'm not clear on what standard would do in a server environment here....

Since this is quite an increase, we should investigate better tree shaking when the feature isn't used

I shall take a look @JeanMeche - but i am struggling to run the integration tests locally (i bumped all the size.json from the output in the gh test runner output),

I get:

ERROR  Failed to switch pnpm to v10.23.0. Looks like pnpm CLI is missing at "/var/folders/kj/cqmyhbyx0zv7mrtvpdlj19dw0000gp/T/ng-integration-test7nTJJM/tmp-env-0/Library/pnpm/.tools/pnpm/10.23.0/bin" or is incorrect
spawnSync /var/folders/kj/cqmyhbyx0zv7mrtvpdlj19dw0000gp/T/ng-integration-test7nTJJM/tmp-env-0/Library/pnpm/.tools/pnpm/10.23.0/bin/pnpm ENOENT
Command failed: `pnpm install`

🤔