4 ms·

Can you elaborate exactly where the unbounded lookahead is required? I genuinely can't see it. I also don't see why a dramatic update like this couldn't also in

Can you elaborate exactly where the unbounded lookahead is required? I genuinely can't see it. I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I feel like we're talking serious edge cases here.

lucideer 4y ago
> Can you elaborate ... I'm not sure I can think of a better explanation/examples than the gp. It essentially comes down to ambiguity between single element selector names (which are unprefixed in CSS - no dot or hash) and property keys (also plain identifiers). The only similar nested braces form we have in current CSS is always @-prefixed. There's no unprefixed equivalent for parent blocks in current syntax (plus those blocks are currently limited to a single level which I guess mightt simplify things further given the prefixed selector is always at root level) > I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I think it could and I think the call for input is open to that as a possibility. The above comment is just referring to a fully compatible direct scss implementation of nesting.
- somishere 4y ago
  I get your point. However it relies on an example that actually requires an unbounded lookeahead. This is where I'm confused. Sure, these ambiguous blocks (I'm not sure how many examples there are other than color:hover) aren't prefixed, but they are conclusively postfixed. So any lookahead required should be easily bounded. Where does the unbounded aspect come into it? Reposting my earlier painfully phone-typed regex to illustrate the point: https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1 Edit: I should add that I don't doubt that those involved know what they're talking about. I know nothing of briwser-level CSS parsing. I am certain it is a nightmare. I would really just like a better example to explain the unbounded aspect. Especially when it is being given as the primary excuse to cripple / greatly obtusify a syntax I'm being asked for an opinion on. Maybe it's just me but I would expect that an evolution of this magnitude would afford a bit more compromise elsewhere.
  - assbuttbuttass 4y ago
    I think when we talk about "unbounded lookahead," it means the lookahead can't be bounded by any constant. A common type of parser is called LR(1), meaning it can only lookahead by 1 character.[0] The advantage of only looking ahead by a constant is that parsing can be done in linear time. For a backtracking parser, you have to look ahead by up to n characters each time, leading to a quadratic runtime in the worst case. [0] https://en.m.wikipedia.org/wiki/LR_parser https://en.m.wikipedia.org/wiki/LR_parser
    - somishere 4y ago
      Thanks for the explanation/link, appreciate it. I'll reserve my cynicism of using this as a reasoning to hold-up progress.
Ericson2314 4y ago
Do you want a new attack vector to make your browser crash? It's not like all CSS is crafted benevolently!
- somishere 4y ago
  malevolent css targeting non-performant regex .. sounds utterly despicable.
madeofpalk 4y ago
You've just turned this one spec proposal into two! I thought this was about simplifying things, not doubling the amount of work.
- somishere 4y ago
  you've got to break a few eggs.. Seriously tho it seems like a pretty major feature to be introducing. Why not do it right? Surely the complexity should be concealed rather than out front being dealt with in user space.

lucideer 4y ago

> Can you elaborate ... I'm not sure I can think of a better explanation/examples than the gp. It essentially comes down to ambiguity between single element selector names (which are unprefixed in CSS - no dot or hash) and property keys (also plain identifiers). The only similar nested braces form we have in current CSS is always @-prefixed. There's no unprefixed equivalent for parent blocks in current syntax (plus those blocks are currently limited to a single level which I guess mightt simplify things further given the prefixed selector is always at root level) > I also don't see why a dramatic update like this couldn't also introduce / require a 'strict' style to be considered valid. I think it could and I think the call for input is open to that as a possibility. The above comment is just referring to a fully compatible direct scss implementation of nesting.

somishere 4y ago
I get your point. However it relies on an example that actually requires an unbounded lookeahead. This is where I'm confused. Sure, these ambiguous blocks (I'm not sure how many examples there are other than color:hover) aren't prefixed, but they are conclusively postfixed. So any lookahead required should be easily bounded. Where does the unbounded aspect come into it? Reposting my earlier painfully phone-typed regex to illustrate the point: https://regex101.com/r/aOc2Pz/1 https://regex101.com/r/aOc2Pz/1 Edit: I should add that I don't doubt that those involved know what they're talking about. I know nothing of briwser-level CSS parsing. I am certain it is a nightmare. I would really just like a better example to explain the unbounded aspect. Especially when it is being given as the primary excuse to cripple / greatly obtusify a syntax I'm being asked for an opinion on. Maybe it's just me but I would expect that an evolution of this magnitude would afford a bit more compromise elsewhere.
- assbuttbuttass 4y ago
  I think when we talk about "unbounded lookahead," it means the lookahead can't be bounded by any constant. A common type of parser is called LR(1), meaning it can only lookahead by 1 character.[0] The advantage of only looking ahead by a constant is that parsing can be done in linear time. For a backtracking parser, you have to look ahead by up to n characters each time, leading to a quadratic runtime in the worst case. [0] https://en.m.wikipedia.org/wiki/LR_parser https://en.m.wikipedia.org/wiki/LR_parser
  - somishere 4y ago
    Thanks for the explanation/link, appreciate it. I'll reserve my cynicism of using this as a reasoning to hold-up progress.

Ericson2314 4y ago

Do you want a new attack vector to make your browser crash? It's not like all CSS is crafted benevolently!

somishere 4y ago
malevolent css targeting non-performant regex .. sounds utterly despicable.

madeofpalk 4y ago

You've just turned this one spec proposal into two! I thought this was about simplifying things, not doubling the amount of work.

somishere 4y ago
you've got to break a few eggs.. Seriously tho it seems like a pretty major feature to be introducing. Why not do it right? Surely the complexity should be concealed rather than out front being dealt with in user space.