- From: davidwebca via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Sep 2021 16:19:42 +0000
- To: public-css-archive@w3.org
Mmm that's an interesting idea that I didn't consider honestly. That's one thought I was bouncing around in my head when we were exchanging in the previous few comments: "@" rules usually have a set of specific rules (@keyframes, @media, etc.) and allow for specific functionalities, but nesting is just... allowing selectors inside a block , so why would we need an "@" rule when it's just about styles? In that sense, the nested "style" declaration from @proimage makes syntactical sense. Usually, at-rules only use parenthesis when there's a need to use special characters such as colons inside the arguments. Ex.: @supports (display:flex), @media _screen_ and **(min-width:280px)** So an interesting idea that would be easy on existing parsers would look like: ```scss .card { display: block; (article&) { display: flex; } } ``` would yield ```css .card { display: block; } article.card { display: flex; } ``` But this conversation is running in circles because we're trying to solve three friction points at once when it might not be possible: 1. Combine the two syntaxes (starting with & and @nest) into one to avoid confusion 2. Prevent superfluous pressure on parsers by starting nested rules with a special character, ideally one that is not & to avoid confusion with its previous selector reference purpose. 3. Try and reuse existing pre-processor syntaxes to facilitate migration Also I want to clarify something about my previous comments on "reverse parsing". I didn't mean "let the parser do it's thing, parse and reverse engineer the selectors afterward". What I meant was to start parsing by the deepest level of nested blocks because it's easy to infer that the previous "rule" is a selector (what precedes "{" is always a selector or an "@" rule). It might be what they already do internally and I wouldn't know about it 🤷 but in that case, it would mean we don't need a starting character at all. -- GitHub Notification of comment by davidwebca Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4748#issuecomment-930330228 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 September 2021 16:19:44 UTC