Correct me if I'm wrong, but my interpretation of the lookahead is that performance only degrades once CSS becomes deeply nested.
That the need to lookahead only applies to syntax nested within another block.
It's not a realistic use case for somebody to nest CSS more than a few levels deep, and if the lookahead is a known part of the spec it would become a best practice not to excessively nest things.
So with side by side implementations, what's the cost in time/CPU of a realistically scoped CSS file with a realistic level of nesting? That's the answer I'd like to know.
Optimizing for an avoidable theoretical worst case shouldn't be a major consideration in design.
The net result of using a weird syntax for nesting is that developers will just keep using preprocessors forever because they're far more ergonomic. So all the spec saves is some built file size, while not improving anything about the development process
That the need to lookahead only applies to syntax nested within another block.
It's not a realistic use case for somebody to nest CSS more than a few levels deep, and if the lookahead is a known part of the spec it would become a best practice not to excessively nest things.
So with side by side implementations, what's the cost in time/CPU of a realistically scoped CSS file with a realistic level of nesting? That's the answer I'd like to know.
Optimizing for an avoidable theoretical worst case shouldn't be a major consideration in design.
The net result of using a weird syntax for nesting is that developers will just keep using preprocessors forever because they're far more ergonomic. So all the spec saves is some built file size, while not improving anything about the development process