Comment by lucideer | Hacker News Reader

Comment by lucideer | Hacker News Reader

Parent Full thread

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

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

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.

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

Thanks for the explanation/link, appreciate it. I'll reserve my cynicism of using this as a reasoning to hold-up progress.

Reply on news.ycombinator.com