Re: [csswg-drafts] [css-mixin-1] How does Shadow DOM influence mixin lookup? (#12671)

@emilio said in https://github.com/w3c/csswg-drafts/issues/13041#issuecomment-3492008333:

> [@sorvell](https://github.com/sorvell): it seems to me [#12627 (comment)](https://github.com/w3c/csswg-drafts/issues/12627#issuecomment-3488556563) is somewhat tangential and is about whether these names would even be applicable across trees (which I don't think they should, I don't think any other such thing does). Custom properties work like that because of inheritance, but that's the exception, not the rule...

It's [literally the rule](https://drafts.csswg.org/css-scoping-1/#shadow-names:~:text=If%20an%20at%2Drule%20or%20property%20defines%20a%20name%20that%20other%20CSS%20constructs%20can%20refer%20to%20it%20by%2C%20such%20as%20a%20%40font%2Dface%20font%2Dfamily%20name%20or%20an%20anchor%2Dscope%20name%2C%20it%20must%20be%20defined%20as%20a%20tree%2Dscoped%20name.). See also the [default dereferencing behavior](https://drafts.csswg.org/css-scoping-1/#tree-scoped-name-loosely-matched:~:text=defaulting%20to%20loosely%20matched%20unless%20otherwise%20specified.%20A%20loosely%20matched%20tree%2Dscoped%20name%20can%20be%20matched%20by%20tree%2Dscoped%20references%20(see%20below)%20in%20the%20same%20tree%20or%20descendant%20trees). A named thing not being visible in the inner scope would be the exception.

As far as I know, you can access outer container names, timeline names, anchor names, keyframes, fonts, counter styles, custom functions, and probably more from the inner scope.

The only confined name-defining thing I can think of is `@layer`. I don't see a strong thematic connection between layers and a mixins, and therefore no need to apply a similar confinement to mixins.
 
> I guess it depends on whether you take `@mixin` as a feature of the stylesheet or something more dynamic like `@keyframe` tho... But `@mixin` last I checked could "instantiate" nested rules and so on, so we can't easily move it to style application time (let me know if I'm missing something [@andruud](https://github.com/andruud)).

Yeah, since `@apply` expands into arbitrary nested selectors, we indeed cannot move all of `@apply`'s effects to style application time. Regardless, I would expect mixins to follow the established pattern, and make themselves available to inner scopes. I can _live with_ a resolution that confines them (it's easier anyway), but it's not an outcome that currently makes sense to me. 

---

Quoting myself from earlier:

> I consider that [tree-crossing order dependence] incompatible with the mixins-are-order-dependent-for-simplicity resolution in [#12417](https://github.com/w3c/csswg-drafts/issues/12417). Rules are processed independently _per tree_, and having order-dependence cross shadows would require that processing to happen in the context of a particular spot in the flat tree (which is not calculated at the time that processing takes place). This is much less simple than just dropping order-dependence altogether.

After working on this some more, I now somewhat disagree with this. (That's allowed, right?) If we _really_ want mixins as defined at the point where a given shadow host exists, it should be approachable. But I do think it's better if we let inner scopes "inherit" the _final_ mixins seen in the outer scope, i.e. the set of mixins after all sheets in that scope are fully processed. This is easier to deal with, and also ensures that mixins arriving from adopted stylesheets in the outer scope are visible in inner scopes. Failing that, let's at least use the regular tree, and not the flat tree.

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12671#issuecomment-3492962390 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 5 November 2025 19:29:31 UTC