Re: [csswg-drafts] [css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules (#8738)

> (Especially if the only reason Sass & other tools made their choice is that they could not implement the more intuitive behavior.)

They absolutely *could* have implemented either behavior; it's just outputting a separate rule rather than combining into one rule. They do exactly that if you *do* wrap the latter declaration in a `& {...}` rule, so both behaviors are clearly possible.

> I do not believe it's correct for these two blocks to end up with different results:

I think the consistency argument is reasonable in either direction. Before nesting, if you wrote:

```css
h1 {
  color: yellow;
  color: green;
}
```

you'd get a single 'color' declaration with the value green. One can reasonably argue, I think, that it's also consistent that adding an unrelated rule (the `@media` in your example) shouldn't change the behavior of these declarations. I suspect that might be why the preprocessors originally chose the behavior that they did.  Adding an explicit `& {...}` wrapper around the latter declaration is a much stronger declaration of intent than just inserting an unrelated rule before it.

------

I have no strong opinion on which way we go for this. But the fact that the current spec *is* the behavior of essentially every preprocessor, and afaict there have been approximately zero complaints about it for over a decade of use (because, again afaict, nobody actually writes code like that in the first place), means that there's very little reason for *us* to care about what the behavior is either. As such I'd prefer no change, as compatibility with the wider ecosystem is a (minor) benefit, but I won't object over the rest of the WG if the decision goes the other way.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1765516899 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 17 October 2023 01:36:40 UTC