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

> I was not talking about selectors, I was talking about a something that is not yet in the language?

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.

> Well, by indefinitely you mean until the next char or line where the parent closes with }?

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

*If* you eventually see a `;` or a `{`, then you know the preceding tokens were a declaration or a selector, but that can happen *arbitrarily far away* from the start of the token sequence; you can keep it ambiguous as long as you want. Thus it requires infinite lookahead to tell them apart, which is something that browsers wanted to avoid. (Currently you can parse CSS with a single token of lookahead, which makes parsing much easier and cheaper.)

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

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

> one @nest to solve the readability of the first to be introduced? And on the @nest you still have to use the ampersand.

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

> ```
> & class_2 {}
> &.class_2 {}
> ```

And compare both of those with `&+class_2`; it's also the same length, with some arbitrary punctuation between the `&` and the `class_2`, but we don't consider it confusable with either of the above. The descendant combinator is a basic part of CSS used many times in every stylesheet; we don't need to protect people from it.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6119#issuecomment-803620887 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 16:51:56 UTC