3 ms·

> `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

by 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.

by aasasd 4y ago

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.