Passed TGP

@GeorgySerga I tested your change and the first regression that I reported in #58226 is still present.

Given this code:

:host {
  &:not(&.foo, &.bar) {
    color: red;
  }
}

It produces the following in your PR:

[_nghost-%COMP%]:not([_nghost-%COMP%].foo,.bar[_nghost-%COMP%]){color:red}

It previously produced this:

[_nghost-%COMP%]:not([_nghost-%COMP%] .foo, .bar)[_nghost-%COMP%]{color:red}

Since the changes in 18.2.8 have only been reverted on the 18 branch and not for 19, we would currently see the same regression again. I noticed that you added a test for this case. Is the new output now the one you consider correct? Is this change now intentional? In which case this should be marked and documented as a breaking change.

@LeonEck fwiw, the breaking change window for v19 is now closed. Either we're able to land a non-breaking fix or this fix will also be reverted in v19 (until a non-breaking one can land).

Hi @LeonEck , thank you! I don't think I quite understand the example you shared. If I understand correctly

:host {
  &:not(&.foo, &.bar) {
    color: red;
  }
}

should be (after sass conversion)

:host:not(:host.foo, :host.bar)

(a host element, which is not a host with class .foo or host with class .bar) and therefore converted to what you shared [_nghost-%COMP%]:not([_nghost-%COMP%].foo,.bar[_nghost-%COMP%]){color:red} by Angular.

Could you please share more? Thanks!

I added several variations of those selectors into the tests here as well, so you can take a look: https://github.com/angular/angular/pull/58557/files#diff-874bc712ebc9efc52417f6e744bd2b118514d58405dd2c31df0ae467ff297840R86-R100 .

@GeorgySerga I think the [_nghost-%COMP%] that directly follows the .bar could be the issue why it isn‘t working anymore. But my main concern is that we have code that relies on the current output. So any change, even a change that might make it more correct, I beliefe should be treated as a breaking change, given that the current behavior was like that for years.
To us this is especially a concern since we are publishing a library. So without us changing anything, users that update to Angular 19 would see broken styles. And even if we wanted to prepare a fix beforehand, given that Angular 19 is expected in a week, we would need to know the compiler behavior asap.
I would like to see the same revert done in 69dce38 on the Angular 19 branch so that behavior doesn’t change for now. And after Angular 19 is released there is more time to look into this and decide what output the compiler should produce.

Thank you @LeonEck ! Addressing this part

I think the [_nghost-%COMP%] that directly follows the .bar could be the issue why it isn‘t working anymore.

Styles apply regardless of order in this case .class[attribute] or [attribute].class
https://jsbin.com/rebudibeze/edit?html,css,output

I edited your example so it includes the whole output that Angular produces: https://jsbin.com/rirogosiri/edit?html,css,output

The gold version is the "old" output that Angular 18 produces and that we rely on.

The aquamarine is what Angular 19 currently produces. And that one is not applying the color.

It does not, indeed, but it is correct. Both elements there have classes applied: .foo on one of them, .bar on the other. The selector says to not apply the styles to these elements :not(:host.foo, :host.bar).

EDIT: added a link to a bin with class applied if the host has a different class, .baz: https://jsbin.com/fucogaroxe/edit?html,css,output , but not to the other two instances, excluded by the selector.

@GeorgySerga I've opened #58681 with your commits as we want to target the main branch

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}