Re: [csswg-drafts] [css-nesting] Syntax suggestion (#4748)

_@LeaVerou wrote:_
> 
> Nope, not at all. Zero extra indentation.
> 
> I'll explain with some examples.
>
> * snip *

Ahh, I had indeed misunderstood that idea. To be honest I'm not crazy about that specific implementation... nothing about the string of chars `&{}` says to me "This is the start of nested selectors", and the other options of just requiring the first selector to start with `&` while the rest don't have that requirement just seems... arbitrary? Like, `&` still represents the parent selector, but _if_ it comes first in a selector line, then treat it as a delimiter instead/as well? I dunno, something bugs me about multi-purpose bits of code that have non-obvious meanings depending on a non-obvious context.

Granted, the `@nested;` or `@nestStart ... @nestEnd` delimiters don't help fix the non-obvious context issue any, but at least their meanings are more obvious to CSS authors.

_@tabatkins wrote:_
> > [ideas about delimiter-based nesting]
> 
> I'm strongly against ideas in this form. It's a parsing mode switch, which is slightly awkward technically but not killer, but it means that the parsing context you're in is less obvious, which isn't great for authors. It's also very awkward to manipulate with the OM - are those at-rules that should show up in the OM? If so, what happens when you move them into a bad order? Or are they just syntactic indicators that don't show up in the OM at all?

Hmm... let me respond to your questions with a question of my own: Given the current proposed standard of "`&` or `@nest` before every nested CSS rule" , how would _those_ nested rules show up in the OM? Because in my admittedly non-programmer brain, delimiting a block of nested selectors and their properties with unique keywords or characters is basically like telling the parser "When `@nestStart` is encountered, prepend `@nest` in front of each selector until `@nestEnd` is reached." So as far as I'm concerned, any selector within a `@nestStart ... @nestEnd` block would be treated and interacted with in the OM exactly the same way that selectors with explicit `@nest` prefixes are now.

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


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

Received on Thursday, 11 November 2021 22:16:26 UTC