6 ms·

The article answers this exact question already. It isn't possible because there's no build stage like preprocessors have to remove ambiguity.

dalmo3 4y ago
If the preprocessors can remove the ambiguities, so could the browsers. If the concern is speed, then just stick with the status quo (my preference, but sadly not an option in the poll).
- Timon3 4y ago
  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?
  - dmitriid 4y ago
    > 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.
    - Timon3 4y ago
      I don't see how this is the case here: - 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?
- tnzk 4y ago
  Your comment makes me feel like this is another form of "New Product helps a googler's promotion, but improving an existing product doesn't" attitude.
- bornfreddy 4y ago
  This. And if you want a different solution, offer it through transpiling, and if people like it, then implement it in the browsers. Not the other way around, forcing on us a standard that noone likes. Otherwise just use sass, it is well-liked and proven. Or, as you suggest, do nothing.
- somehnacct3757 4y ago
  It's a lose/lose situation. If you resolve the ambiguity in real time in favor of the preprocessor syntax, you break existing websites. If you perform a preprocessing step it now blocks CSS parsing and slows down all websites on the internet. Maybe the preprocessor authors should have thought harder about their syntax if they wanted it to be adopted as a web standard.

dalmo3 4y ago

If the preprocessors can remove the ambiguities, so could the browsers. If the concern is speed, then just stick with the status quo (my preference, but sadly not an option in the poll).

Timon3 4y ago
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?
- dmitriid 4y ago
  > 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.
  - Timon3 4y ago
    I don't see how this is the case here: - 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?
tnzk 4y ago
Your comment makes me feel like this is another form of "New Product helps a googler's promotion, but improving an existing product doesn't" attitude.
bornfreddy 4y ago
This. And if you want a different solution, offer it through transpiling, and if people like it, then implement it in the browsers. Not the other way around, forcing on us a standard that noone likes. Otherwise just use sass, it is well-liked and proven. Or, as you suggest, do nothing.
somehnacct3757 4y ago
It's a lose/lose situation. If you resolve the ambiguity in real time in favor of the preprocessor syntax, you break existing websites. If you perform a preprocessing step it now blocks CSS parsing and slows down all websites on the internet. Maybe the preprocessor authors should have thought harder about their syntax if they wanted it to be adopted as a web standard.