🐛 BUG: Nesting At-Rules break all proceeding CSS

[jonathantneal]

What version of astro are you using?

0.21.10

What package manager are you using?

npm

What operating system are you using?

Mac, Linux

Describe the Bug

Nesting at-rules as described in the 2013 CSS Syntax specification, the latest CSS Syntax specification, and the current CSS Nesting specification break all proceeding CSS in a <style> block.

I have also filed an issue with the dependency that I believe to be causing this.

Given the following HTML, what do you expect is the text color of the body, and what do you expect is the background color of the body?

<style>
/* CSS Example 1 */
body { @media (min-width: 640px) { color: blue } }
body { background-color: pink }
</style>

You should expect the body text to be blue when either the framework or browser supports CSS nesting, and you should expect the body background to definitely be pink. This is observable on CodePen, whether you enable PostCSS tooling or not.

Now, given the following similar HTML, what do you expect?

<style>
/* CSS Example 2 */
:global(html) { @media (min-width: 640px) { color: blue } }
html { background-color: lime }
</style>

You should expect the answers to be the same (substituting body for html), as long as the framework supports :global.

However, the background is never pink nor lime, the text is never blue, and none of these declarations are ever actually rendered.

<style astro-style="true">/* CSS Example 2 */html{@media(min-width:640px){</style>
<style astro-style="true">/* CSS Example 1 */body{@media(min-width:640px){</style>

The curious ordering aside, it appears the handler for CSS quietly gives up parsing the rest of the stylesheet.

Possible Solutions

I would like to suggest a minimal solution, a preferable solution, and an ideal solution. Let me be clear that these are my own personally-ranked suggestions.

I believe a minimal solution would be to support the behavior described in the 2013 specification. This means a nesting at-rule would be consumed, and its contents would be printed as-is, with no scoping applied.

I believe a preferable solution would be to support the behavior described in the 2021 specifications. This means all nesting rules would be consumed, and any selectors would have the appropriate scoping applied.

I believe an ideal solution would be to support the behavior described in the 2021 specifications, with some additional ability to transform the nesting into pre-nesting-compatible code.

Again, these are my own personally-ranked suggestions.

Alternative Solutions

If is not feasible to fix the upstream CSS parser, then as an alternative I would suggest Astro warn authors whenever an error from the CSS parser is thrown.

I appreciate that Astro does not throw for CSS or HTML. It’s very web-like, and I like it.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-77dfin?file=src/pages/index.astro

[natemoo-re]

Leaving some search keywords here for folks looking for this issue:

• CSS nesting, CSS nested, nested CSS
• Container Query, Container Queries, @container
• Media Query, Media Queries, @media