- From: Emilio Cobos Álvarez via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 14:10:43 +0000
- To: public-css-archive@w3.org
While I'm not a huge fan of needing multiple passes, it does seem a reasonable trade-off if we only need _one_ extra pass for all these rules, which I understand to be the case? I.e. the TLDR of this approach seems to be:
* Do a first pass over all potentially-matching rules to figure out dependencies between supports / media / layer.
* Do cycle resolution / resolve the final layer order. Details a bit TBD I guess? But seems reasonable.
* Do a second pass over rules again with the "frozen" set of conditions.
Did I understand it correctly?
I guess that also means that you do need to visit children of all the potentially-matching conditional rules on the first pass (which is a behavior difference between `@media (never-matching) { ... }` and `@custom-media --never-matching (never-matching); @media (--never-matching) { ... }`). But IIUC that's mostly an implementation detail.
I do think custom supports having a totally different loading behavior than non-custom supports is really unfortunate fwiw... You _could_ squint a bit and make an argument about how `<link rel=stylesheet href=.. media=print>` has totally different render-blocking behavior to `@import url(..) print;`, but changing whether you do the load at all seems rather unfortunate for something that ideally would just be syntactic. It might be the least bad of both worlds tho, I guess? I'm not sure I've made my mind about how bad it is :)
Just to confirm, these two examples behave the same with the proposal, right?
```css
@media (never-matching) {
@layer foo, bar;
}
@layer bar, foo;
```
vs.
```css
@media (--never-matching) {
@layer foo, bar;
}
@layer bar, foo;
```
Tracking layer definition conditionally is fairly annoying, but I think it is the only reasonable way to go around it, if we take this route... Right now defining a new layer is basically bumping a counter, this complicates it significantly, but oh well :')
--
GitHub Notification of comment by emilio
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13041#issuecomment-3778331128 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 14:10:44 UTC