[css-nesting-1] Declaration occuring after an invalid nested rule

[cdoublev]

Declarations occuring after a nested rule are invalid and ignored.

https://drafts.csswg.org/css-nesting-1/#mixing

Does this mean that a declaration occuring after an invalid nested rule is valid? For example:

ul {
  @invalid;
  padding-inline-start: 1em;
}

If so, I suggest:

Declarations occuring after a valid nested rule are invalid and ignored.

Related: https://github.com/w3c/csswg-drafts/issues/7286

[sesse]

Another suggestion: Can we just drop this entire demand? I don't see a good rationale for it, and it complicates parsing (we need to remember whether any nested rules have been seen, and if so drop declarations—but only declarations). Furthermore, what is valid or invalid depends on the implementation status of the UA, so this hurts forward compatibility.

[astearns]

From what I understand, there was some concern about how to represent interleaved declarations and selectors in CSSOM, and worry that browsers would have to store this interleaving in order to resolve order of appearance. So we have this section that requires rules to come after declarations to simplify both issues.

But in a very cursory glance at a couple of codebases using PostCSS nesting, I found several instances of declarations coming after rules - sometimes in ways that made perfect sense to me in how one might want to group styling decisions. So I wonder if the restriction is worth having.

We could let authors interleave declarations and rules as they like, then define both CSSOM and order of appearance to do the grouping automatically. Order of appearance would just have one more rule that nested declarations are always placed “after” top-level declarations in a block.

This would cause problems for the implicit rule switch currently proposed, but I am not a fan of that spooky-action-at-a-distance, anyway.

@tabatkins @argyleink @fantasai @mirisuzanne

[romainmenke]

But in a very cursory glance at a couple of codebases using PostCSS nesting, I found several instances of declarations coming after rules - sometimes in ways that made perfect sense to me in how one might want to group styling decisions. So I wonder if the restriction is worth having.

We tried to follow the specification but this conflicted with mixins and other syntactic sugar build around at rules in the PostCSS ecosystem.

.foo {
  @mixin foo;

  color: red;

  .bar {
    color: green;
  }
}

When we added a warning that all declarations must precede at rules we immediately got feedback that we broke all the things.

Unhappy side-effect of this is that people can mix and match nesting and declarations.

.foo {
  color: red;

  .bar {
    color: green;
  }

  padding: 20px;
}

Long story short, the PostCSS plugins for nesting are not a good reference point for this question.

[astearns]

@romainmenke can you go into why this is an unhappy side-effect? Do you have a reason to require rules follow declarations aside from following the current spec?

[romainmenke]

Do you have a reason to require rules follow declarations aside from following the current spec?

That is the only reason. We had to balance breaking a large part of the ecosystem or following the specification.

[tabatkins]

From what I understand, there was some concern about how to represent interleaved declarations and selectors in CSSOM, and worry that browsers would have to store this interleaving in order to resolve order of appearance. So we have this section that requires rules to come after declarations to simplify both issues.

Yeah, basically there's no way to represent the interleaving correctly "as written", so interleaved declarations would be interpreted as if all the properties were moved to the start and rules were placed after.

That's not, like, killer, since the only way for it to even theoretically matter is if you interleaved a nested rule that targeted the same elements as the parent without adding any specificity, like & {...} or :where(.foo) & {...} or something. Those are likely extremely rare in the first place.

So, we could allow interleaving them so long as that slight wrinkle to "order of appearance" is okay. (I think it is.) We'd probably still recommend they be put first, tho.

[astearns]

Right, I would rather have a recommendation to put declarations before rules (because that’s how the browser is going to sort them anyway), but not require authors follow that recommendation

[sesse]

Yes, I'm fine with not preserving order of appearance. The spec already says that nested rules are taken to apply as if they were written after the parent rule, so at least the semantics are clear.

If we end up with a parser switch, of course, we cannot have properties after at-rules even if we want to, so I guess this is another issue blocked on that.

[tabatkins]

This issue is now moot, given the changes to the spec to support Option 3. (There is no longer any requirement to put all declarations before all rules.)