W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2018

Re: [csswg-drafts] [css-nesting] request to pick up the css-nesting proposal

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Jun 2018 17:41:37 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-395505518-1528393296-sysbot+gh@w3.org>
> Alternatively, the only ambiguous case is when the selector starts with an element selector, right? If it starts with an id, class, pseudo-class, or pseudo-element, we know immediately.
>
> What if the ampersand was only required in that case?
>
> This will simplify a ton of cases. It has the drawback if being a little less consistent but then again, so was requiring whitespace around + and - in calc(), but we did that.

It's still drawing a more complicated boundary around "what's allowed without @nest", and more damningly, the reasoning *behind* the boundary is relatively arcane parsing concerns, far below the level that an author should have to learn about. This means the boundary will feel *arbitrary* to authors, which is a big strike against in terms of learnability and usability.

Additionally, in current preprocessors `.foo { .bar {...}}` already has a meaning - it's equivalent to `.foo .bar {...}`. It's ambiguous what this should mean in Nesting - is it equivalent to `&.bar` or `& .bar`?

If there really was a big usability benefit from being able to omit the `&` I'd be more willing to consider the tradeoffs, but it's a single character to type, and it makes things less ambiguous anyway. I don't think any exceptions here are worth their weight.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2701#issuecomment-395505518 using your GitHub account
Received on Thursday, 7 June 2018 17:41:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:50 UTC