[csswg-drafts] [css-nesting] & rules (#6119)

mnussbaumer has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting] & rules  ==
First thanks, I think it's great nesting is being added and work being done to provide a flexible spec for it.
I have some reservations towards its implementation and meaning and this came about also because I'm working on a pre-processor for CSS (I didn't even know this was being drafted/added to the css spec until someone pointed it out to me).

In my personal opinion of having written non trivial stylesheets using sass/scss I think that it would help the spec to make it stricter on what it can describe. 

My main issue with the current proposal for `&`, and having two syntaxes with `@nest` is that `&` as described can produce two very different css rules depending on if the `&` is followed by `<whitespace><selector>` or just `<selector>`.

In my mind the nesting with `&` should always mean a concatenation of the selector described afterwards to the parent selector chain(s). This means, `&.concatenated` and `& .not-contatenated` have very different meanings, one applies the concatenation and attributes inside the block to the whole selector, e.g. `btn.concatenated`, while the latter creates a simple selector hierarchy, e.g. `btn .not-concatenated` where the attributes inside the nested block apply only to an element with class .not-concatenated inside a btn element. I think this is confusing.

In the most common pre-processors you can usually have nested with or without `&` and a nested selector without `&` means that it's just a simple hierarchy. This also diminishes the visual noise. You no longer have to pay attention extensively to the white-spacing between `&` and you can see immediately if a selector is `gluing` - becoming part of the parent - or if it's a children of the parent.

This would also simplify the parsing:
- parsers, IDEs, tooling (and even browsers) could produce errors/warnings on `&` when followed by spaces giving clear information on how it's not being used correctly
- `&` could only be placed at the beginning of a selector inside a block
- for simple nesting (hierarchical) you wouldn't need to use `&` inside a block. Right now I'm not seeing  any ambiguity in there - if inside a block and the declaration is not `<text><colon><text><semicolon>` and does not start with `&` it's a nested selector ?
- (personal) I also think it becomes less ambiguous and visually more telling

I would go as far as not allowing `&`nesting of non selector tokens. I've seen used sometimes, things like (just to illustrate)
```scss
btn {
    height: 30px;
    &.btn- {
      &xl { height: 40px; }
      &sm { height: 20px; }
    }
}
```

Where the nesting concatenates "plain" text into the parent chain. I think this shouldn't be allowed because you can't grep a file to find the class .btn-xl or .btn-sm. So perhaps it would make sense to force `&` to be followed by a valid selector, meaning, starting with `.`, `#`, `[`, etc, or an html tag when the parent to concatenate is not itself an html tag (since you can only have a selector point to at most one tag).

Not sure if this is useful but since I've been thinking about this for my own work decided to share my thoughts on it.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6119 using your GitHub account


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

Received on Friday, 19 March 2021 08:41:57 UTC