I don't think this would cause any functional problems - authors can still order layers as they want, and then add imported styles to those layers. But it does make the syntax for that a bit less flexible.

Yeah, no functionality is lost here, just a bit of flexibility. But I'd be okay with the restriction; it's probably better practice to put your @layer ...; rule either before or after your imports anyway.

Agenda+ to get a resolution

The CSS Working Group just discussed disallow interweaving of @import and @layer, and agreed to the following:

• RESOLVED: @layer statements must occur before or after all @imports, not interleaved

@mirisuzanne Your edits also disallow interleaving among @layer and @namespace, is there a reason for that?

@fantasai That was a request from @xiaochengh, as I understand it had to do with the same parsing/performance concerns mentioned above. Maybe he can speak to it more here.

Yes, I requested that the rules should follow the exact ordering I initially proposed.

The reason is that there's no loss of functionality, and the implementation in Chromium gets much simpler.

I see that the spec got adjusted in ed81c17 for this, but I'm a bit confused by the use of the word "They" in the note.

Note: They are not allowed between (or intermixed with) @import and @namespace rules …

That "They", does it mean:

1. @layer statement at-rules (from the title of that section)?
2. @layer block at-rules (mentioned as the last few words just above the note)?
3. Both

A few thoughts that go with all these options:

• If option 1: then the first syntax in EXAMPLE 31 (listed just underneath it) would be invalid, no?

• If option 2: it's pretty unclear to me to know that "They" targets only this type of @layer at-rules. It also feels a bit redundant, as this guideline is also noted in another note above it (“Note: @layer block at-rules cannot be interleaved with @import rules.”).

• If option 3: How would one append extra local CSS to the theme layer of EXAMPLE 31? I guess that would only be possible by creating extra sub-layers inside theme?

  @layer default, theme, theme.overrides, components;
  @layer theme.overrides {
    /* Override theme "base" layer here */
  }
  
  @import url(theme.css) layer(theme);

  Feels weird to first have to write the overrides, and only then load its base layer.

I think option 2 is meant, but I'm not really sure reading all comments and logs here, as it's not explicitly mentioned 🤔

@bramus option 1 is the intended behavior, though it's only intended to mean that any @import and @namespace rules can't have intervening @layer statements. The example shows the opposite -- one @import between @layer statements -- which is allowed. I can try to add more clarity there…

Thanks for the clarifications on that, @mirisuzanne. Think I get it now:

/* EXAMPLE 31 */
@layer default;
@import url(theme.css) layer(theme);
@layer components; /* 👈 This @layer statement here will make all subsequent @import rules be ignored. In this example however there are none */

@layer default {
  audio[controls] {
    display: block;
  }
}

I see that in d9fdc1e you changed the text to “A ''@layer'' rule that comes after …”. More precise would be “A ''@layer'' statement at-rule that comes after …”?

Winging back to “the @layer block at-rule” described just above it. There it reads in a note:

Note: @layer block at-rules cannot be interleaved with @import rules.

Is that 1 @import rule in between two @layers block at-rules? If so, I somewhat read between the lines that best practice that's being hinted at is to:

1. Establish a layer order upfront using @layer statement at-rules
2. Group your @imports after that
3. Append styles to already established layers using @layer block at-rules

Would that be something to recommend people to do?

(Apologies if I'm asking too many stupid questions regarding this. Trying to understand things correctly here. Perhaps some code-examples of what is meant by all those limitations could help? In css-nesting-1 for example I see a lot of these “wrong examples“ with an explanation of what exactly is wrong added to them.)

@bramus Yes, your summary of best practice is correct. Though another common practice is to avoid using @import entirely for performance reasons. :)

Only the empty layer-ordering statements are allowed before @import/@namespace, but once we encounter an @import/@namespace rule, then either type of @layer rule will make additional @import/@namespace rules invalid. So I think the current text is correct. Basically, you can't put anything else between @import/@namespace rules, those have to be applied in a single block without intervening rules.

Thanks again for the extra input there. Current spec text indeed is correct; wanted to verify if I laid the pieces together correctly :)

@bramus clarified in the example. See 7726486