4 ms·

Take a better look at example 5: [1]. In that case, the `@nest` marker is necessary for proposal 1. Proposal 2 is saying, if we need @nest some times, why not a

Take a better look at example 5: [1]. In that case, the `@nest` marker is necessary for proposal 1. Proposal 2 is saying, if we need @nest some times, why not always make it required, for consistency. In that example, I'd say proposal 3 is the least ugly. However, it's unclear to me why we want to allow the & marker to appear anywhere in a rule, and not just at the start. Every time I've used nesting in a CSS pre-processor, I've always added to the selector at the end. [1] https://developer.chrome.com/blog/help-css-nesting/#example-5-parent-nesting-or-subject-changing https://developer.chrome.com/blog/help-css-nesting/#example-...

aasasd 4y ago
The example by itself doesn't explain why I can easily grok that `.parent &` is a selector with nesting, but the parser can't. The `&` marker is introduced for nesting in the first place, so adding another one to specify that it's definitely hundred-percent pinky-swear artisanal nesting looks plain dumb.
- vgel 4y ago
  It requires unbounded lookahead in the parser.
  - deleted 4y ago
    [deleted]
  - vgel 4y ago
    I got a reply asking why this is, which either got deleted or isn't showing up for some reason. The reason is, before nesting, you know based on context whether something is a selector or a declaration. Top level / inside a media query, it's a selector. Inside a selector, it's a declaration. With nesting, but without the prefixed @nest, you have backtrack after arbitrarily many tokens if you see a & and need to switch from parsing a declaration to parsing a selector. E.g.: div { div:hover div /* 4kb of div */ & { } } Note that the colon makes it a valid-looking declaration (property `div` and value `hover div...`), until you read all the way up to the &.
    - aasasd 4y ago
      Yeah, it's all quite simple when thinking for a bit on a clear head. For some reason I didn't realize at first that the whole ‘:hover’ problem only pops up when nesting is introduced.
robocat 4y ago
> if we need @nest some times, why not always make it required, for consistency Prefixing a parent selector seems super ugly. The facility is available in SCSS, but I suspect it is not used much (e.g. comment above not knowing the feature existed). Using & for the usual case of appending selectors seems sensible to me. Aside: I suspect using & to avoid lookahead parsing is important for efficiency and to avoid DoSing the browser (especially malevolently).

aasasd 4y ago

The example by itself doesn't explain why I can easily grok that `.parent &` is a selector with nesting, but the parser can't. The `&` marker is introduced for nesting in the first place, so adding another one to specify that it's definitely hundred-percent pinky-swear artisanal nesting looks plain dumb.

vgel 4y ago
It requires unbounded lookahead in the parser.
- deleted 4y ago
  [deleted]
- vgel 4y ago
  I got a reply asking why this is, which either got deleted or isn't showing up for some reason. The reason is, before nesting, you know based on context whether something is a selector or a declaration. Top level / inside a media query, it's a selector. Inside a selector, it's a declaration. With nesting, but without the prefixed @nest, you have backtrack after arbitrarily many tokens if you see a & and need to switch from parsing a declaration to parsing a selector. E.g.: div { div:hover div /* 4kb of div */ & { } } Note that the colon makes it a valid-looking declaration (property `div` and value `hover div...`), until you read all the way up to the &.
  - aasasd 4y ago
    Yeah, it's all quite simple when thinking for a bit on a clear head. For some reason I didn't realize at first that the whole ‘:hover’ problem only pops up when nesting is introduced.

robocat 4y ago

> if we need @nest some times, why not always make it required, for consistency Prefixing a parent selector seems super ugly. The facility is available in SCSS, but I suspect it is not used much (e.g. comment above not knowing the feature existed). Using & for the usual case of appending selectors seems sensible to me. Aside: I suspect using & to avoid lookahead parsing is important for efficiency and to avoid DoSing the browser (especially malevolently).