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

Thanks for taking the time to reply. I will preface by saying that my concern is related to complexity and the syntax becoming less intuitive than it could be, from the point of an user. As I said before, it's not that I can't understand the chosen tradeoffs, and ultimately I can choose to write my own preprocessor that works just as I want it to and outputs valid css, and so does anyone else. I also imagine it's complex to handle the process of implementing changes into such a widely use thing while keeping all interests in sight. I'm still going to argue though :)

> I mean that the difference between X.foo and X .foo is already how Selectors work. Nesting doesn't change anything about this; the nesting selector & works exactly the same as any other selector in this regard.

But that's how selectors work in css2, `&` is a new token, yes the top-level selectors use spaces to define the chain of selection between them, but not a prefix with a space between them to signal. 

> No, I meant indefinitely; that is, for as long as it wants.

This is the same as it is already, the spec allows `/` multilines (which I guess it shouldn't because anybody writing selectors with multilines deserves their styling to be broken, yes the html spec allows it, but the css shouldn't in my opinion), and any token bound by delimiters can do exactly the same thing, from `"text.........` to `[attri......]`, to `url("base64....."` .
So that problem is already there.

> And if you never see either (because the token sequence ended with a } closing the parent block, or an EOF), then it might not be resolvable at all, and you just have to arbitrarily decide which it is. (If it was a selector this would be an invalid style rule, because it lacks a {} after it, but "invalid style rule" and "valid declaration" still have observably different behaviors, so it's still important which one you guess.)

It's resolvable, if the token sequence ended with a `}`, you add `;` and see if it's a valid rule. If it's not it's a broken query selector because it doesn't open a block? Even if it's a pseudo-selector or class, it has no bearing because it's missing a block, and won't be a valid attribute either way. 

> The current syntax prevents either of these situations from happening. You can tell whether a token sequence is starting a selector or a property according to the very first token you look at - if it's an &, you should start parsing as a selector, otherwise it's a property. (Or you see an @nest token, in which case you parse an at-rule, which is already unambiguous with the other two.)

It prevents that from happening for sure, but it introduces two new declarations targeted at the same functionality. This can result in people using one, or both, across the same codebase or different code bases, instead of having a single way of declaring their intentions. Which is basically more complexity. And because either has different constraints it makes it (or can make it) harder to learn (I'm not saying me, or you, just in general). 

> @nest isn't there for readability, it's to allow you to express the remaining cases that the normal syntax doesn't allow - anything that doesn't start with an & selector, but instead uses the & deeper in the selector. For example, .foo { .bar & {...} } is invalid (because it's not immediately unambiguous, as described above), but you can write .foo { @nest .bar & {...} } and get what you wanted.

This seems to come from exactly not having the ability to do naked nested selectors (as in SCSS)?. Looking at Example # 5 on the draft

```css
.foo {
  color: red;
  @nest & > .bar {
    color: blue;
  }
}

// the scss equivalent is
.foo {
  color: red;
  > .bar {
    color: blue;
  }
}
```
And the other ones seem to follow the same ?

```css
.foo {
  color: red;
  @nest .parent & {
    color: blue;
  }
}

.foo {
  color: red;
  @nest :not(&) {
    color: blue;
  }
}
```
These no longer would have ambiguity correct? 

And these invalid examples
```css
.foo {
  color: red;
  @nest .bar {
    color: blue;
  }
}
/* Invalid because there’s no nesting selector */

.foo {
  color: red;
  @nest & .bar, .baz {
    color: blue;
  }
}
```

Could then be validly written as:
```css
.foo {
  color: red;
  .bar {
    color: blue;
  }
}
/* Invalid because there’s no nesting selector */

.foo {
  color: red;
  bar, .baz {
    color: blue;
  }
}
```

I just think that given how one (at least me, but I imagine more people) think about selectors, in where `.class button` means "a button that is inside an element with class .class" this simple 

```css
.class {
     button {}
}
```

Maps perfectly to it. The nested selector is inside another selector.
I also think that this looks better
```css
div {
   .class_1, &.class_2, .class_3, &#special { }
}

// than this
div {
    & .class_1, &.class_2, & .class_3, &#special {}
}
```
 
> The descendant combinator is a basic part of CSS used many times in every stylesheet; we don't need to protect people from it.

It's another rule one has to know. We do not, but what I find interesting is that some of the arguments you provided are exactly about protecting people from malformed css, so I don't think it's fair ending on that note.

And lastly, this syntax as been used by most major pre-processors, in which most well known css frameworks, that probably thousands of people have used, were written. I'm not saying that that in itself is a reason to not change syntax or introduce new syntax or break away with something, but I do find in this particular case to be clearer. That is of course my own opinion and as the saying goes, everyone has one. I have nonetheless written quite complex stylesheets so I feel like it's not totally worthless to share it. Ultimately this will be part of the spec and I want to have a record of me saying I disagree with it!

Parsers are a dozen, people reading and writing stylesheets are in the millions, death to all non-conformant parsers.

Again thanks for taking the time to reply, have a great week, you can consider this issue closed and answered.
 

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


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

Received on Sunday, 21 March 2021 18:21:30 UTC