4 ms·

I agree it's a big mistake to not make the nesting rules compatible to Sass/Less. > Because of limitations in browser parsing engines, you must make sure the n

I agree it's a big mistake to not make the nesting rules compatible to Sass/Less. > Because of limitations in browser parsing engines, you must make sure the nested selector (.bar in the above example) always starts with a symbol. How hard can it be.. I know that is always easy to say from the outside but in this case I don't understand why the refuse to implement it. Just labelling it as a performance problem doesn't say much because why should it impact performance to check whether there appears another rule with an opening "{" after it.

wruza 4y ago
Iirc, this requires unbounded lookahead. Imagine a CPU that is fast but has no concept of stack, so no recursion/callstack for you. You can simulate it through registers, but only as much as register pressure allows in a finite register file. Allowing unbounded call stack requires changing the class of a CPU to the one that has stack (and is slower, due to analogy is incomplete). In the same way, &-less grammar changes the class of a parser required to parse it. You can’t simply adjust the existing one. In the end it all boils down to the amount of dynamic allocations and backtracking required for parsing the same megabyte of css. Edit: nothing substantial was said about actual numbers, at least from what I’ve read. It’s a common sense that seems nobody has tested (in this particular case).