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

@leaverou

> If preprocessor users haven’t really stumbled on this in the first place, compatibility with preprocessors is not a benefit, minor or otherwise.

Right, but my point is that *neither behavior is a benefit*, according to over a decade of experience. This simply *does not matter to authors*, as far as we can tell. So the "benefit to authors" part of the PoC is approximately 0; at best it's a learnability benefit, but better learnability for a case that doesn't appear to ever happen in practice is worth extremely little. So impl benefits, even minor ones, can weigh sufficiently here to sway the outcome.

> a low-hanging optimization would be to merge them together when it doesn’t change the outcome. 

We cannot do this. What things are raw decls and what are rules is observable in the OM. I absolutely do not want the OM to be dependent on "when it doesn't change the outcome".

> Wrapping declarations in & {} is also technically rewriting, so I think that ship may have sailed?

No, it's not at all rewriting, in the sense that you're suggesting. How we interpret things on the first pass is up to us; you're talking about a *completely different thing* where something would be wrapped in a rule or not depending on the exact property names used across/between *other* rules. (Whether or not the first `@media` in your example used 'gap' would affect whether it "changes the outcome"!) That's an extremely non-local and non-obvious effect, and I'd object strongly to it.

> 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.

We can't do this either, because it would mean that two consecutive `&{...}` blocks would roundtrip into a single one. And I don't think we want to specify that the serialization differs based on whether there's a single or multiple blocks with a particular selector in a row.


@miriamsuzanne

> With mixins it is more clearly important that authors have an easy way to override the output by providing additional declarations after the mixin. In fact, most Sass 'best practices' have encouraged putting mixins before declarations rather than after.

This is a fair argument, and does argue for a real author benefit in doing the rule-wrapping. Sass gets away with it because it's just doing direct substitution of the `@include` with its contents.

Note that Sass's behavior is inconsistent in this regard; for example:

```css
@mixin reset-list {
    & {
        margin: 0;
        padding: 0;
        list-style: none;
    }
}

ul {
    @include reset-list;
    margin: 1em;
}

/* compiles to */

ul {
  margin: 1em;
}
ul {
  margin: 0;
  padding: 0;
  list-style: none;
}
```

So the "trailing" `margin: 1em` gets put before the mixin in the cascade and will be overridden! (Defining the mixin with naked properties rather than a nested rule does do what you suggested, tho.)

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


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

Received on Friday, 20 October 2023 18:07:55 UTC