Potential bug: nesting with unknown AtRule, removes the selector

[RobinMalfait]

Hey!

We are using the nesting feature, and if you nest an @media inside of a rule, it properly gets hoisted to the top and the rule with the selector is put inside the @media AtRule. However, if you try to do this with let's say @container then the selector is gone.

This also happens with any other AtRule it doesn't recognize.

Input:

/* Normal syntax, works */
@container (min-width: 200px) {
  .bar {
    text-decoration-line: underline
  }
}

/* Nested syntax with @container, selector is gone */
.foo {
  @container (min-width: 200px) {
    text-decoration-line: underline
  }

  @any-at-rule {
    color: red;
  }
}

/* Nested syntax with @media, selector is still there */
.baz {
  @media (min-width: 200px) {
    text-decoration-line: underline
  }
}

Current behaviour:

@container (min-width: 200px) {
  .bar {
    text-decoration-line: underline;
  }
}

@container (min-width: 200px) {
  text-decoration-line: underline
}

@any-at-rule {
  color: red;
}

@media (min-width: 200px) {
  .baz {
    text-decoration-line: underline;
  }
}

Expected behavour:

@container (min-width: 200px) {
  .bar {
    text-decoration-line: underline;
  }
}

@container (min-width: 200px) {
  .foo {
    text-decoration-line: underline
  }
}

@any-at-rule {
  .foo {
    color: red;
  }
}

@media (min-width: 200px) {
  .baz {
    text-decoration-line: underline;
  }
}

Is this a bug, or is this the expected behaviour?

---

Reproduction link: https://lightningcss.dev/playground/index.html#%7B%22minify%22%3Afalse%2C%22nesting%22%3Atrue%2C%22customMedia%22%3Atrue%2C%22cssModules%22%3Afalse%2C%22analyzeDependencies%22%3Afalse%2C%22targets%22%3A%7B%22chrome%22%3A6225920%7D%2C%22source%22%3A%22%2F*%20Normal%20syntax%2C%20works%20*%2F%5Cn%40container%20(min-width%3A%20200px)%20%7B%5Cn%20%20.bar%20%7B%5Cn%20%20%20%20text-decoration-line%3A%20underline%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%2F*%20Nested%20syntax%20with%20%40container%2C%20selector%20is%20gone%20*%2F%5Cn.foo%20%7B%5Cn%20%20%40container%20(min-width%3A%20200px)%20%7B%5Cn%20%20%20%20text-decoration-line%3A%20underline%5Cn%20%20%7D%5Cn%5Cn%20%20%40any-at-rule%20%7B%5Cn%20%20%20%20color%3A%20red%3B%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%2F*%20Nested%20syntax%20with%20%40media%2C%20selector%20is%20still%20there%20*%2F%5Cn.baz%20%7B%5Cn%20%20%40media%20(min-width%3A%20200px)%20%7B%5Cn%20%20%20%20text-decoration-line%3A%20underline%5Cn%20%20%7D%5Cn%7D%5Cn%22%2C%22unusedSymbols%22%3A%5B%5D%2C%22version%22%3A%22local%22%7D

[devongovett]

Yeah @container support got added after nesting and looks like I missed it. Should be added in here:

lightningcss/src/parser.rs

Line 839 in 27cb9c2

fn parse_prelude<'t>(

.

Looks like @layer can also be nested, which is interesting. Not sure how that is supposed to work. https://drafts.csswg.org/css-nesting/#conditionals

[devongovett]

Not sure how we should handle @any-at-rule. The spec is clear about which rules are allowed inside nested style rules.

[thecrypticace]

@devongovett I'm not so sure about that unless there's another section somewhere.

The spec itself says (emphasis mine):

… this specification allows nested group rules inside of style rules: any at-rule whose body contains style rules can be nested inside of a style rule as well.

And then, following that, is the introduction a list of at rules:

Specifically, these rules are capable of being nested group rules:

These two together read, to me, as:

1. It doesn't matter what the rule is as long as it has a body that contains style rules.
2. When supporting nesting take care to ensure that all of these at rules are supported because these are all the ones that contain style blocks in this spec.

[devongovett]

hmm well the issue is Lightning CSS doesn't know how to parse @any-at-rule, so it just stores the raw tokens inside the block. It doesn't know that the contents are supposed to be parsed as a declaration list.

[devongovett]

Fixed for @container and @layer in the above commit. I'm not sure if we want to handle custom (unknown) at rules the same way - we currently don't interpret them at all so it would be a little challenging. If this use case is important to you, we can re-open but I'd suggest either processing these rules before sending the CSS to lightning css, or using the custom at rule parsing capabilities via the Rust API (example).