But why? Why does it HAVE to be the existing syntax or nothing? If we know that this syntax would make performance worse, why is an alternative that doesn't do so a worse option than not having this useful feature?
> But why? Why does it HAVE to be the existing syntax or nothing?
Because time and again userland implementations of useful functionality are better, more ergonomic and practical than anything committees come up with.
- the nested CSS proposal supports everything the SCSS syntax does, plus some potentially useful combinations
- the SCSS syntax would literally lead to a worse user experience, both for the end user whose browsing performance is now degraded, and anyone implementing parsers for CSS (since the infinite lookahead is quite a bit more complicated)
- the committee isn't just "coming up" with the new syntax, they are asking for feedback. Let's not pretend this is the same as a committee deciding something without taking input from the affected users.
I understand that generally a de facto standard will be more useful than a de jure one. But this isn't some committee coming up with their own convoluted version of a standard because of NIH - they are communicating clearly and openly around why the established standard would be problematic. Shouldn't we as a technical community try to find the best solution for the problems we face, instead of taking principled stands and ignoring the technical hurdles in our way?
