CSS optimisation is reordering styles in unpredicted way about astro HOT 9 CLOSED

You're doing it the right way, I think this is just a bug with the build. Will look into it.

from astro.

Thanks for raising. What’s happening here is that while we crawl all pages in parallel, styles may be found in different orders. In order to avoid a race condition where styles may be generated in random orders, we alphabetize them, hence why reset appears after global (likely).

But that does break your scenario here where 2 stylesheets do have an explicit order. So that should be preserved. We’ll make a change for that.

As a temporary workaround, you could try loading your reset.css from within a global.scss file using @use (rename the file to .scss but still load .css in your <link> tag). In general, Sass is a very good way to determine order where it matters (and you can still write CSS syntax if you prefer; you don’t have to use any Sass syntax).

from astro.

I actually tried that (as very well documented in the Styling guide) but it didn't work. I'm not sure why but it could be that my reset is overriding some of the scoped rules loaded before that.
If I find time I try to provide more details

from astro.

Opened #232 to fix this. I found an issue which I resolved, where ordering was not deterministic. That automatically closed this issue, but please let me know if you are still experiencing problems.

from astro.

This is fixed in 0.11.0

from astro.

Tried and this is what I see:

TEST1 with

<link href="/css/reset.css" rel="stylesheet"/>
<link href="/css/global.css" rel="stylesheet"/>

RESULT: the bundle css has global first then reset then scoped css.
It's an improvement but should preserve order no ?

TEST2 if I modify to a _reset.scss @use from global.scss
then:

<link href="/css/global.css" rel="stylesheet"/>

RESULT: the bundle css has scoped css then reset and then global.

from astro.

Sorry - failed to upgrade - bare with me

from astro.

Both scenarios work perfectly with 0.11.0 👍
Many thanks!

from astro.

Running 0.23.7 and it seems how you link to global.scss affects the compile order of page and component CSS, when page and component CSS is set to global.

A test repo is available at https://github.com/nonsponsored/astro-css-ordering

Case 1:

Linking global.scss in index.astro via: <link rel="stylesheet" href={Astro.resolve("../styles/global.scss")} />

• In dev, h1 styling comes from Component1.astro. [Expected result]

• In production, h1 styling comes from _base.scss. [Not expected result]

• Production compiled CSS order: index.astro styles, Component1.astro styles, global.scss styles [Not expected result]

Case 2:

Linking global.scss in index.astro via: <style global>@import "../styles/global.scss";</style>

• In dev and production, h1 styling comes from Component1.astro. [Expected result]

• Production compiled CSS order: index.astro styles, global.scss styles, Component1.astro styles [Not expected result]

Note there's a side effect with this approach, and nested styles in _base.scss don't get compiled correctly. For example, the h1 pseudo element compiles to h1{color:#639;&:before{content:"Style from: _base.scss"}}

Expected Result

1. Component styles would always be appended to global.scss, allowing allowing component styles to utilize the cascade.

2. Production compiled CSS order: global.scss styles, index.astro styles, Component1.astro styles

from astro.