Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 BUG: Nesting At-Rules break all proceeding CSS #210

Closed
jonathantneal opened this issue Dec 5, 2021 · 1 comment · Fixed by #329
Closed

🐛 BUG: Nesting At-Rules break all proceeding CSS #210

jonathantneal opened this issue Dec 5, 2021 · 1 comment · Fixed by #329
Assignees

Comments

@jonathantneal
Copy link
Contributor

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

@jonathantneal jonathantneal changed the title 🐛 BUG: Nesting At-Rules break all CSS 🐛 BUG: Nesting At-Rules break all proceeding CSS Dec 5, 2021
@natemoo-re
Copy link
Member

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

@jonathantneal jonathantneal transferred this issue from withastro/astro Dec 6, 2021
@natemoo-re natemoo-re self-assigned this Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants