- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Dec 2022 12:14:43 +0000
- To: public-css-archive@w3.org
In my mind, a merged version of options 3 and 1 tick all the boxes for trying to detect nesting: 1. Starts with any of the existing combinators `>+~`? You’re nesting. 1. Starts with a selector that starts with a symbol`.:#[*`? You’re nesting. 1. Starts with the new `&` combinator? You’re nesting. 1. Starts with `@nest` _(to be used if you want to use `&` somewhere but not at the start)_? You’re nesting. Anything else would fall back to the current mechanism to detect declarations, nested at-rules, etc. Rules 3 and 4 in the list of checks above are the bail out mechanism for when an element selector is nested, similar to what option 1 of the syntax provided us with. These two rules (3 and 4) also play nice with the first two rules, as they can be used together: for example teams can choose to make `@nest` mandatory by using a linter, while giving other people the freedom to not do so. _(Note that I’m sticking with `@nest ` instead of `@ ` for [reasons explained here](https://github.com/w3c/csswg-drafts/issues/8253#issuecomment-1364520043))_ -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8249#issuecomment-1364520559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 24 December 2022 12:14:45 UTC