5 ms·

Choosing only among the given proposals, what I see is one clear, concise and reasonably elegant syntax, and two ugly and noisy ones. Frankly it vaguely feels l

by aasasd 4y ago

Choosing only among the given proposals, what I see is one clear, concise and reasonably elegant syntax, and two ugly and noisy ones. Frankly it vaguely feels like the two latter options are there just to shepherd the ‘community’ (if there's such a thing) toward the least egregious variant and offer a semblance of discussion. It's not even necessarily bad that there's one obviously best option, if it's dictated by technical constraints—just, why bother me with the other two? If they're seriously considering the latter two options for us to be stuck with, that's very concerning, and I'll be nervous about the whole affair until something definite rolls out. Of course, it might be that the syntax authors foresaw some future problems that I don't, but their arguments aren't provided. In fact, I don't even see why the `@nest` marker is necessary at all. The W3C draft says, “Some valid nesting selectors, like `.foo &`, are disallowed”—but why? They introduced the `&` marker to tell nesting rules apart from anything else, but then it turns out that they can't do that with the marker either? See `&` anywhere in the selector, realize it's a nesting—how much lookahead is needed for this? `&` can't be in a property name or media rule, can it? Surely there's a reason for this constraint, only I can't figure it out—granted, I barely know anything about implementing a CSS parser. (Update: text cited by @pointlessone notes that a nest-selector might look like `color:hover & something`, which is indeed quite wacky and apparently befuddles the parser.) Also, philosophically, a more-verbose marker like `@nest` would help avoid the growth of ascii salad in the syntax (the way that Python and Lisp avoid it, compared to Bash and Perl)—specifically if the marker was used instead of both `@nest` and `&` together in those proposals. However, it's probably not such an issue in regard to a feature that's gonna get plenty of exercise and is practically core functionality.

Ericson2314 4y ago
- aasasd 4y ago
  The post makes it quite clear that all three proposals sprinkle some markers and constrain their use to avoid ambiguity for the parser, so not sure what you're talking about.
  - Ericson2314 4y ago
    The more markers you sprinkle, the less ambiguous the grammar should be.
- gpmcadam 4y ago
  nesting them, if you will
emn13 4y ago
Regardless of the merits and feasibility of implicitness vs. explicitness, I seriously question whether it's ever a good idea to mix the two. That's just asking for confusion exactly in those cases where selectors are confusing already; i.e. adding complexity where it hurts most.
JW_00000 4y ago
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
> `color:hover & something` Though then again, I still don't see why the parser can understand that `color:hover something` is a selector, but can't understand that `color:hover & something` is a selector with nesting. I don't need to mark a shitty selector like `color:hover` with special markers for shitty selectors, do I?
- aasasd 4y ago
  Update: it finally dawned on me that only with nesting things like `color:hover` can appear where both properties and selectors are expected. Apparently today is not my thinking day. Still would like to understand exactly how ‘unbounded lookahead’ arises.
  - WorldMaker 4y ago
    Lookahead is how many tokens the parser needs to see before it can make a decision what branch it is in and start ingesting those tokens properly. In `& color:hover` you've got at least four tokens (making some basic assumptions about how the tokenizer works and ignoring whitespace): 1 & 2 color 3 : 4 hover In this case you've got that `&` in the first token and the parser knows what to do with that (only appears in nesting scopes). (No lookahead needed.) In the case of `color:hover &` the situation reverses: 1 color 2 : 3 hover 4 & Tokens 1/2/3 are ambiguous (could be a property:value or could be tag selector:state) and it isn't until token 4 that it becomes obvious that it must be a nested selector because that & token is the disambiguator. So here you need a lookahead of 4 tokens just to disambiguate. The problem is "unbounded" because the way selectors and values work they can be arbitrarily long. You can have "long property values". This doesn't make a lot of sense in current CSS, but is a valid property value assignment: color:hover, tt, .frankenstein, p; This is a possible (weird) nesting: color:hover, tt, .frankenstein, p & { } The number of tokens needed to lookahead is "unbounded" because you can keep adding tokens to that weird property value or to the nesting example with no clear limit.
    - aasasd 4y ago
      Thanks! In fact I easily see this myself now that I've gotten some sleep. Really can't recommend sitting at the computer for hours.
Spivak 4y ago
Honestly I think "@nest always" makes the most since since it would be consistent with @media and unmagic the leading '&'. It gives @nest the feel of printf.
- spiralx 4y ago
  But the example with multiple selectors and & at the start is unclear due to the precedence of the @nest operator over the comma: /* @nest always */ @nest & + .baz, &.qux { color: red; } It's clearer perhaps with different nesting, but that's fragile and a pain: /* @nest always */ @nest & + .baz, &.qux { color: red; } At least with option 1 you only end up with this issue in the uncommon case of multiple selectors and a non-leading &. /* @nest */ & + .baz, &.qux { color: red; }
clairity 4y ago
yah, i have a strong preference for the first option, and don't mind that it requires using an & token relative to scss that requires none. the @nest always option seems overly verbose, and adding more brackets visually overloads them in a way that makes it harder to parse quickly when scanning.
psygn89 4y ago
I think option 1 is the most elegant, but I also realize that as a user of Less and Sass it is the most natural choice for me. The `@nest` having to appear when the ampersand exists after any other character in the line is an okay inconsistency for me, since I rarely come across that form and when I do it it's in short bursts with tightly coupled selectors. You can also think of it as a warning sign for yourself that you have an ampersand in a not-so-conventional spot in the line. If option 2 happens I wouldn't be disappointed, either. The brackets example, however, just looks wrong to me.
hiimshort 4y ago
I also found the second and third options unnecessarily noisy. Though, I'm not surprised with the obvious syntax warts being proposed considering the disaster that is `globalThis`. I do hope the first choice is the one used as it is the most reasonable while working around existing CSS parsing rules.

by aasasd 4y ago

Ericson2314 4y ago

aasasd 4y ago
The post makes it quite clear that all three proposals sprinkle some markers and constrain their use to avoid ambiguity for the parser, so not sure what you're talking about.
- Ericson2314 4y ago
  The more markers you sprinkle, the less ambiguous the grammar should be.
gpmcadam 4y ago
nesting them, if you will

emn13 4y ago

Regardless of the merits and feasibility of implicitness vs. explicitness, I seriously question whether it's ever a good idea to mix the two. That's just asking for confusion exactly in those cases where selectors are confusing already; i.e. adding complexity where it hurts most.

JW_00000 4y ago

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

> `color:hover & something` Though then again, I still don't see why the parser can understand that `color:hover something` is a selector, but can't understand that `color:hover & something` is a selector with nesting. I don't need to mark a shitty selector like `color:hover` with special markers for shitty selectors, do I?

aasasd 4y ago
Update: it finally dawned on me that only with nesting things like `color:hover` can appear where both properties and selectors are expected. Apparently today is not my thinking day. Still would like to understand exactly how ‘unbounded lookahead’ arises.
- WorldMaker 4y ago
  Lookahead is how many tokens the parser needs to see before it can make a decision what branch it is in and start ingesting those tokens properly. In `& color:hover` you've got at least four tokens (making some basic assumptions about how the tokenizer works and ignoring whitespace): 1 & 2 color 3 : 4 hover In this case you've got that `&` in the first token and the parser knows what to do with that (only appears in nesting scopes). (No lookahead needed.) In the case of `color:hover &` the situation reverses: 1 color 2 : 3 hover 4 & Tokens 1/2/3 are ambiguous (could be a property:value or could be tag selector:state) and it isn't until token 4 that it becomes obvious that it must be a nested selector because that & token is the disambiguator. So here you need a lookahead of 4 tokens just to disambiguate. The problem is "unbounded" because the way selectors and values work they can be arbitrarily long. You can have "long property values". This doesn't make a lot of sense in current CSS, but is a valid property value assignment: color:hover, tt, .frankenstein, p; This is a possible (weird) nesting: color:hover, tt, .frankenstein, p & { } The number of tokens needed to lookahead is "unbounded" because you can keep adding tokens to that weird property value or to the nesting example with no clear limit.
  - aasasd 4y ago
    Thanks! In fact I easily see this myself now that I've gotten some sleep. Really can't recommend sitting at the computer for hours.

Spivak 4y ago

Honestly I think "@nest always" makes the most since since it would be consistent with @media and unmagic the leading '&'. It gives @nest the feel of printf.

spiralx 4y ago
But the example with multiple selectors and & at the start is unclear due to the precedence of the @nest operator over the comma: /* @nest always */ @nest & + .baz, &.qux { color: red; } It's clearer perhaps with different nesting, but that's fragile and a pain: /* @nest always */ @nest & + .baz, &.qux { color: red; } At least with option 1 you only end up with this issue in the uncommon case of multiple selectors and a non-leading &. /* @nest */ & + .baz, &.qux { color: red; }

clairity 4y ago

yah, i have a strong preference for the first option, and don't mind that it requires using an & token relative to scss that requires none. the @nest always option seems overly verbose, and adding more brackets visually overloads them in a way that makes it harder to parse quickly when scanning.

psygn89 4y ago

I think option 1 is the most elegant, but I also realize that as a user of Less and Sass it is the most natural choice for me. The `@nest` having to appear when the ampersand exists after any other character in the line is an okay inconsistency for me, since I rarely come across that form and when I do it it's in short bursts with tightly coupled selectors. You can also think of it as a warning sign for yourself that you have an ampersand in a not-so-conventional spot in the line. If option 2 happens I wouldn't be disappointed, either. The brackets example, however, just looks wrong to me.

hiimshort 4y ago

I also found the second and third options unnecessarily noisy. Though, I'm not surprised with the obvious syntax warts being proposed considering the disaster that is `globalThis`. I do hope the first choice is the one used as it is the most reasonable while working around existing CSS parsing rules.