This is being requested for TAG feedback because it is a CSS-wide behavior change (well, behavior definition), and interacts with shadows and their information-hiding/componentization, so want to make sure we're not missing anything wrt platform consistency or other issues.

The examples Xiaocheng cites are indeed a great in-depth explanation of the behavior, but in short, the behavior is:

• Whenever a property references an at-rule by name, the keyword for the name is a "tree-scoped reference", and remembers what tree its stylesheet is in. When it needs to find the referenced at-rule, it looks in that tree specifically, even if it's been inherited or assigned to elements deeper in nested shadows.

  This ensures that components can't accidentally clash with at-rules defined outside of themselves, unintentionally changing the meaning of inherited or ::part()-inserted values. (Without this, a well-behaved component would have to give their at-rules UUID-ish names to have a high likelihood of avoiding clashes.)

• If a tree-scoped reference can't find the named at-rule in its remembered tree, it walks up the tree-of-trees to find the name in an ancestor scope. (Or, put another way, at-rules "inherit" down into shadows.)

  This mimics the implicit information-leakage that CSS already purposely allows with property inheritance, particularly inheritance of custom properties. It also means that a page can use in-house components that reference things like @font-faces it knows will exist in the outer document. Accidental clashes can only occur if a component is expecting this "inheritance" to work, but is nested inside of a foreign component that also uses the same name; this is the exact same failure scenario that custom properties have.

@xiaochengh from a multi-stakeholder PoV: from the linked discussion in CSS it looks like Firefox is also implementing. Can you confirm?

Hi @xiaochengh @tabatkins!

We looked at this during the plenary today and overall we are happy with the direction this is going and think the proposed reference mechanism is intuitive. However, we noticed that the linked resolution is tentative, has there been another resolution? If so, could you link to it?

It was only tentative in the sense that if we found any compat constraints due to existing wild behavior, we might need to capture that as a special case. As you can see from the partially-filled-in table at https://wiki.csswg.org/spec/css-scoping, there's zero agreement and a lot of cases simply don't work at all today, but the bits of behavior that do work are largely consistent with the resolved/specified behavior, so most code that works today should probably continue to work.

We haven't had a further resolution since that, since compact impact would need to be assessed to go further (and Chrome is gonna be the first to start implementing these behaviors).

@torgo I've requested for Firefox's position here: https://github.com/mozilla/standards-positions/issues/556

Right now they haven't confirmed yet

We discussed this in our plenary session today, and overall we're really happy with where this has ended up in terms of the authoring experience. It would be hard to come up with a solution more intuitive to component authors. We note that this may have implementation complexity impact, so we encourage the WG to solicit implementor feedback from engineers familiar with the innards of each of the three engines.