- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 20:46:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-mixin-1] How does Shadow DOM influence mixin lookup?`, and agreed to the following: * `ACTION: fantasai to talk to Antti and get back a Webkit position on this.` * `SUMMARY: Desire to have mixins be loosely matched, but concerns about performance and implementation complexity.` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: @mixin defines a named rule, like other global name-defining rules<br> <fantasai> TabAtkins: I believe the right answer is to lean on our existing functionality for scoping<br> <fantasai> TabAtkins: if you're in a shadow DOM stylesheet, we look in that shadow DOM, then walk up the tree looking for the name<br> <lea> q+<br> <fantasai> TabAtkins: just like font faces<br> <fantasai> TabAtkins: So that the shadow DOM can reference its own font faces safely, but also reference the parent DOM's fonts when needed<br> <castastrophe> +1<br> <fantasai> TabAtkins: Similarly, would be able to define a mixin in the parent scope and use them into the shadows<br> <kbabbitt> +1<br> <miriam> +1<br> <emilio> q+<br> <astearns> ack lea<br> <fantasai> PROPOSED: Mixins use loosely-matched tree-scoped references<br> <fantasai> lea: +1<br> <fantasai> lea: very strong use cases in the community for this behavior<br> <astearns> ack emilio<br> <fantasai> emilio: Main concern with this is that it makes the global styles affect rules of shadow trees.<br> <bkardell> yeag<br> <lea> q+<br> <bkardell> yeah*<br> <fantasai> emilio: Mixins are weird because they do introduce rules into a scope. They can have child rules, selectors, etc.<br> <fantasai> emilio: So they get applied at a totally different time than things that inherit.<br> <fantasai> emilio: Issue here is that shadow DOM styles are generally isolated from the rest of the page<br> <fantasai> emilio: Blink is the only engine that has a global system<br> <fantasai> emilio: Data stored because not just that stylesheet, but also all the parent scopes.<br> <fantasai> emilio: I think it's also an issue for Webkit<br> <fantasai> lea: To be clear, not looking into a shadow, only looking up<br> <fantasai> lea: There's questions around implementation difficulty, but strong signals from author community that this is what they want.<br> <fantasai> lea: It won't inadvertently affect the shadow's styles, because we prioritize the inner scopes.<br> <castastrophe> q+ how do keyframes work for shadow trees? Keyframes do inherit between shadow trees<br> <fantasai> emilio: That's my main concern, would like to hear from WebKit wrt implementability and performance.<br> <astearns> ack lea<br> <fantasai> castastrophe: For @keyframes, is that an implementation approach we could re-use? Is there a difference?<br> <fantasai> emilio: They are totally different. Keyframes get looked up after the element has been styled.<br> <fantasai> emilio: They don't affect other rules inside that stylesheet set.<br> <fantasai> lea: What if we resolve that the desire is for them to inherit down, but pending implementation info.<br> <fantasai> emilio: The reason why it works in Blink is because they don't have per-shadow-tree rule-data<br> <fantasai> emilio: But that has other implications like site invalidation being slower, etc.<br> <fantasai> emilio: It's very easy for us to detect when a change is a no-op, for example.<br> <fantasai> astearns: Any alternative? Author feedback seems to be pretty clear.<br> <castastrophe> q+<br> <fantasai> lea: One of the ways authors are working around the problems currently is that authors walk the stylesheets manually and pull them in. Wouldn't that be slower?<br> <fantasai> emilio: You're not doing that automatically all the time.<br> <fantasai> TabAtkins: Would this objection also apply to custom media?<br> <fantasai> emilio: Yes.<br> <fantasai> TabAtkins: Seems similar to question of "what do we need to restyle" for class changes, which, use bloom filters<br> <fantasai> emilio: It's totally different. [gestures]<br> <fantasai> emilio: Bloom filter is for ancestor selectors. you're not in this subtree, don't need to look.<br> <kbabbitt> q+<br> <fantasai> TabAtkins: Concern is that it would be expensive to re-evaluate all the shadow trees.<br> <fantasai> TabAtkins: but if you know ahead of time, they're not using the mixin, then you don't have to check.<br> <fantasai> emilio: ...<br> <fantasai> emilio: It's a significant implementation difficulty that Blink doesn't suffer<br> <astearns> ack castastrophe<br> <fantasai> castastrophe: From my own work and talking to web components CG, this is a huge blocker.<br> <lea> +1 castastrophe<br> <fantasai> castastrophe: Can't use mixins the way they want.<br> <fantasai> castastrophe: If there's a way to create some kind of commitment that we're not updating a mixin once it's defined, or something...<br> <fantasai> castastrophe: We already have perf issues with massively nested shadow DOM anyway. Would rather take the perf hit than try to solve all these problems with JS.<br> <lea> q?<br> <lea> q+<br> <fantasai> emilio: Is that perf issue specific to Blink?<br> <fantasai> castastrophe: Lots of DIV soup.<br> <fantasai> castastrophe: Adobe is a great example. Photoshow is so many nested components.<br> <fantasai> castastrophe: They're trying to do crazy things with theming.<br> <bkardell> s/Photoshow/Photoshop<br> <fantasai> castastrophe: But if cut out those use cases, then not getting out of JS<br> <fantasai> emilio: So the issue is the tree size?<br> <fantasai> emilio: Is it about depth of the *shadow* tree or depth of the tree?<br> <fantasai> castastrophe: They claimed it was shadow trees, but I don't have access any more.<br> <fantasai> castastrophe: We had a theming base class. Every component was inheritng that base class. Mixins would solve that, could use loosely scoped mixins would reduce the need for these base classes.<br> <astearns> ack kbabbitt<br> <fantasai> kbabbitt: Shadow-piercing combinator?<br> <fantasai> TabAtkins: Had one, backed it out.<br> <fantasai> kbabbitt: If I used that in a selector in a mixin, that would effectively ... would that be different perfwise than this?<br> <fantasai> TabAtkins: that's part of why we dropped it<br> <fantasai> emilio: Not going to formally object, but I think it's very foot-gunny if you have mixin use deep in your tree<br> <fantasai> emilio: need to rebuild everything all the way up<br> <fantasai> emilio: Also what does that do to the encapsulation of the shadow DOM?<br> <fantasai> emilio: We try to not expose the structure of the shadow DOM to the light, but you can put any selector you want in there.<br> <fantasai> TabAtkins: because it would be the shadow actively using the mixin, it's ok<br> <fantasai> castastrophe: Is the main concern that it introduces selectors? Or is also an issue of properties?<br> <fantasai> emilio: Anything affecting nested CSS rules causes this issue.<br> <fantasai> emilio: Fact that you can inject arbitrary selectors there, and they can affect the shadows.<br> <fantasai> emilio: Is what you want just inheriting blocks of properties?<br> <Kurt> q+<br> <fantasai> castastrophe: That's a big chunk of it. Have a button and want to extend the styles. But not all of them.<br> <fantasai> emilio: But that include things like &:hover?<br> <fantasai> castastrophe: yes<br> <fantasai> emilio: so it's the same issue<br> <astearns> ack lea<br> <fantasai> lea: One thing was around use cases, castastrophe mentioned one -- if you want to have a button in your shadow DOM that you want to style like buttons on the main page<br> <fantasai> lea: right now very challenging. But with mixins can just use a mixin and pass it in.<br> <emilio> q+<br> <fantasai> lea: One thing to say, sounds like problem is having data structure about what shadow roots exist on the page<br> <fantasai> emilio: we have that, it's just slow to update<br> <fantasai> lea: I mean an O(1) data struct<br> <castastrophe> The primary use-case for web components as I see it is core mixins definitions at the document root and web components extending those mixins inside the shadow dom<br> <fantasai> lea: :has-shadow was proposed. Custom media. Tree walking shadow roots. Lots of use cases for it.<br> <fantasai> emilio: It's O(N) structure, but N can be really big.<br> <fantasai> lea: Performance can always improve. But behavior you're stuck with.<br> <fantasai> lea: This isn't a case where it doesn't matter that much. There are really strong use cases.<br> <astearns> ack Kurt<br> <Kurt> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md<br> <fantasai> emilio: Challenge the use cases.<br> <fantasai> Kurt: Here's a proposal I'm working on for shadow root adopted stylesheets.<br> <fantasai> Kurt: It's efficient because the stylesheet instance is shared between them.<br> <fantasai> Kurt: This avoids some of the perf issues.<br> <fantasai> Kurt: I'm curious if there are edge cases this doesn't cover.<br> <fantasai> emilio: That's a much more explicit mechanism.<br> <fantasai> castastrophe: This is a great feature, but different from what we're talking about.<br> <fantasai> castastrophe: Way web components engineers want to use styles is for parts of styles.<br> <fantasai> castastrophe: for parts of shadow dom, style them<br> <fantasai> castastrophe: opting into certain features, stacking them in a way that's readable<br> <fantasai> castastrophe: You're controlling and limiting what the component does.<br> <fantasai> castastrophe: Right now we load the entire stylesheet for the entire style system when all we want is the button.<br> <fantasai> castastrophe: We're doing in excess<br> <fantasai> castastrophe: Mixins got community excited was the idea of being able to pull in just want we need, and combine parts of a system inside different shadow DOMs<br> <lea> a+<br> <lea> q+<br> <fantasai> Kurt: So instead of applying entire sheets, it's applying specific rules down one at a time.<br> <fantasai> Kurt: Could those sheets be broke up and used this way?<br> <fantasai> castastrophe: Possibility of dynamicism. So many different ways to do a button. If you're building a larger component, and it has a button in shadow DOM. Rather than doing a web component button, do a web component stylesheet definitions, and when you have a button in your markup (like a dialog or toast or whatever), you extend the styles for that specific use case.<br> <fantasai> castastrophe: Rather than having a separate component that does all the things for the button.<br> <lea> q?<br> <fantasai> Kurt: could that be put in a separate sheet and loaded?<br> <fantasai> castastrophe: But then you'd have a ton of tiny little sheets.<br> <fantasai> castastrophe: We're doing button. And then butotn with this. And primary button. And link button. These are all different variants.<br> <fantasai> castastrophe: if you just need to style something, pull them in with CSS<br> <fantasai> castastrophe: If you're bulding a new component, different.<br> <fantasai> castastrophe: This is exciting because we can mix and match. But not going to scale if we need to load 20 parts as style sheets.<br> <fantasai> castastrophe: Back to photoshop. It's one big component, and a bunch of tiny ones.<br> <fantasai> castastrophe: Want to remove the tiny ones and just use mixins.<br> <fantasai> castastrophe: That's a perf gain.<br> <fantasai> Kurt: Differentiator here is level of granularity for the styles. Even if small and many, it's efficient.<br> <lea> q?<br> <fantasai> emilio: I like to see some of the use cases written. How would you write this with mixins?<br> <fantasai> emilio: A lot of the things would end up being as efficient or more efficient if you shared the rules.<br> <fantasai> emilio: Use case: I want all my design tokens. Pulling that via mixin is terrible idea. Applying to thousands of elements instead of inheriting from one.<br> <fantasai> emilio: Re-using adopted stylesheet mechanism or whatever, explicit that "these are the rules I want in my tree".<br> <fantasai> emilio: but mixins inherit through shadow trees is implicit<br> <castastrophe> Another theming use-case might be the theming layering - "base brand" + "product brand" overrides<br> <lea> ack emilio<br> <fantasai> emilio: You might accidentally load new stylesheet that has a mixin, which has an impact on page load that you didn't expect.<br> <fantasai> emilio: It's a pain implementationwise, and footgun performance-wise.<br> <astearns> ack lea<br> <fantasai> lea: First, this is not a session about @sheet. That was presented at TPAC and some pushback on that.<br> <fantasai> lea: What's important about mixins is that they decouple selectors from styles.<br> <fantasai> lea: @style re-uses chunks as styles as they are. No scoping. No parameterization<br> <fantasai> lea: You can have a single mixin that you can pass to multiple components.<br> <fantasai> lea: Ideal is to mix and match components from different sources.<br> <fantasai> lea: You can define your button mixin, and alias it for differnet components.<br> <fantasai> lea: but with @sheet you need a very tight couping between your styles and the component. But you don't control the component.<br> <fantasai> lea: The benefit of mixins is being able to communicate with minimal handshake.<br> <castastrophe> Loosely-scoped mixins has a huge potential of helping us solve the issue of web components reimplementing existing components just for "branded" styling.<br> <fantasai> ACTION: fantasai to talk to Antti and get back a Webkit position on this.<br> <fantasai> astearns: Given what I've heard so far, this is kinda necessary for mixins.<br> <castastrophe> Do we need some more practical use-cases for web components + loosely-scoped mixins?<br> <fantasai> astearns: Not sure I'd want mixins that weren't addressable in shadow DOM<br> <fantasai> emilio: Conceptually if you want flexibility of mixins, you can have a stylesheet that defines your mixins, and import that.<br> <fantasai> emilio: it's the same thing as inheriting into shadow.<br> <fantasai> emilio: just a quesiton of whether you're doing explicitly or not<br> <fantasai> astearns: but that's an extra step...<br> <fantasai> SUMMARY: Desire to have mixins be loosely matched, but concerns about performance and implementation complexity.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12671#issuecomment-4172869205 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 20:46:35 UTC