Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

I think some arguments from Tab in #5738 are still very relevant against the new proposal:

- It keeps the value space more consistent between "direct" nesting and `@nest` nesting - the only change is the *new ability* introduced by `@nest` to put the "&" somewhere different. The less differences there are between the two cases, the more learnable it is.

(The current spec has 2 cases, I have lost track of how many different variants the new proposal has. So less learnable)

- *more than one `&` is allowed in a nesting selector*, so the presence of an `&` later in the selector does *not* indicate that the selector shouldn't also start with an `&`! This is *why* garden-path problems are insidious, as they indicate non-local influences; an author can start with a perfectly reasonable selector with no `&` at all, relying on the implicit `&` at the start, then later use an `&` inside of a pseudo-class and suddenly have the selector drastically change its interpretation. (For example, changing `@nest .foo .bar {...}` to `@nest .foo .bar:not(&) {...}`.) One could try to come up with rules to handle this, but I assure you they won't be complete, and they will drastically complexify the syntax surface here, which is a huge code smell.

- Defaulting to a descendant selector, as preprocessors do, isn't the best thing perf-wise. I'd still rather have authors *intentionally* use the descendant selector than opt them into it by default because it's the shortest way to write something.

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


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

Received on Saturday, 8 October 2022 00:29:56 UTC