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

@emilio 
> An argument for keeping it could be performance, mostly. E.g., if you do something like:
> [snip]
> If we generate a bunch of split rules for anything after an `@media` rule, that can cause useless overhead, which is also surprising.

Given that this doesn’t happen much, I don’t think that would be significant in practice. Also, I suspect when people write code that way (with a declaration, and then a MQ after it to set just that property), the MQs are not that varied, so a low-hanging optimization would be to merge them together when it doesn’t change the outcome. Meaning:

```css
.foo {
 grid-template-columns: auto 1fr auto;
 @media (width < 500px) {
  grid-template-columns: auto 1fr;
 }
 
 gap: .5em;
 @media (width < 500px) {
  gap: .3em;
 }
}
```

becomes:

```css
.foo {
 grid-template-columns: auto 1fr auto;
 gap: .5em;

 @media (width < 500px) {
  grid-template-columns: auto 1fr;
  gap: .3em;
 }
}
```

This is also consistent with our rule to [serialize to the shortest equivalent syntax](https://github.com/w3ctag/design-principles/issues/284#issuecomment-773611014). 

@mdubet 
> the serialisation will generally be more verbose

Not if we go the other way and decide to serialize *all* `& {}`s after rules as bare declarations. Which would also be consistent with our rule to favor the shortest equivalent syntax on serialization. This would also be more likely to preserve author intent, since I bet most `& {}` rules would have come from wrapping bare declarations, rather than specified explicitly by the author.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1766698348 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 15:49:41 UTC