3 ms·

All of these are stupid. Why can’t we just have the scss syntax? It’s already proven.

by donatj 4y ago

mrcartmeneses 4y ago
100% agree. The community has already chosen the syntax it wants by voting with its feet for SCSS
- esteth 4y ago
  Except that syntax requires infinite lookahead to parse. It's feasible when you're running a preprocessor on your own code one time, but not feasible for the browser to do on unknown code on every stylesheet it encounters.
  - bornfreddy 4y ago
    I'm quite sure some edge cases could be forbidden to speed ip parsing. The most common use in my experience is simple nesting ("& .child"), and I would argue other forms should be avoided for readability reasons anyway. But finding 3 other solutions (because of "performance"), not promoting them through transpiling, and then forcing them on web devs seems... googley. Not the first improvement they forced down our throats and unfortunately not the last. /rant
  - marcosdumay 4y ago
    You can just bound the lookahead on the browser by some large number, and accept smaller performance loses for parsing. Anyway, if your possibilities are only nested selector and property, why don't you compute both until they are not ambiguous anymore? You don't need backtracking.
- myfonj 4y ago
  Jake Archibald points out [1] section [2] in that page that explains it somehow. Haven't grokked it yet, but I see that popular SASS (SCSS)-BEM way of doing .block { &__element { &--modifier { p: v; } } } for getting .block__element--modifier { p: v; } could really be problematic from CSS parser perspective. Also in SASS `&` really is kinda placeholder and I think you can do stuff like .x { &+&+& { p:v; } } to get .x + .x + .x { p: v; } what again seems problematic. (But again, I don't say I've grasped that fully.) [1] https://twitter.com/jaffathecake/status/1552200992179077126 https://twitter.com/jaffathecake/status/1552200992179077126 [2] https://developer.chrome.com/blog/help-css-nesting/#:~:text=Why%20can%27t%20the%20exact%20nesting%20example%20shown%20above%20be%20the%20syntax%20for%20CSS%20nesting%3F https://developer.chrome.com/blog/help-css-nesting/#:~:text=...
progbits 4y ago
Naive question: doesn't it have to be something old browsers will ignore rather than misinterpret or fail to parse? The 3rd party CSS tooling can pick whatever syntax it wants because it is starting on a green field. Browser probably can't?
somehnacct3757 4y ago
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?

All of these are stupid. Why can’t we just have the scss syntax? It’s already proven.

by donatj 4y ago

All of these are stupid. Why can’t we just have the scss syntax? It’s already proven.

mrcartmeneses 4y ago

100% agree. The community has already chosen the syntax it wants by voting with its feet for SCSS

esteth 4y ago
Except that syntax requires infinite lookahead to parse. It's feasible when you're running a preprocessor on your own code one time, but not feasible for the browser to do on unknown code on every stylesheet it encounters.
- bornfreddy 4y ago
  I'm quite sure some edge cases could be forbidden to speed ip parsing. The most common use in my experience is simple nesting ("& .child"), and I would argue other forms should be avoided for readability reasons anyway. But finding 3 other solutions (because of "performance"), not promoting them through transpiling, and then forcing them on web devs seems... googley. Not the first improvement they forced down our throats and unfortunately not the last. /rant
- marcosdumay 4y ago
  You can just bound the lookahead on the browser by some large number, and accept smaller performance loses for parsing. Anyway, if your possibilities are only nested selector and property, why don't you compute both until they are not ambiguous anymore? You don't need backtracking.
myfonj 4y ago
Jake Archibald points out [1] section [2] in that page that explains it somehow. Haven't grokked it yet, but I see that popular SASS (SCSS)-BEM way of doing .block { &__element { &--modifier { p: v; } } } for getting .block__element--modifier { p: v; } could really be problematic from CSS parser perspective. Also in SASS `&` really is kinda placeholder and I think you can do stuff like .x { &+&+& { p:v; } } to get .x + .x + .x { p: v; } what again seems problematic. (But again, I don't say I've grasped that fully.) [1] https://twitter.com/jaffathecake/status/1552200992179077126 https://twitter.com/jaffathecake/status/1552200992179077126 [2] https://developer.chrome.com/blog/help-css-nesting/#:~:text=Why%20can%27t%20the%20exact%20nesting%20example%20shown%20above%20be%20the%20syntax%20for%20CSS%20nesting%3F https://developer.chrome.com/blog/help-css-nesting/#:~:text=...

progbits 4y ago

Naive question: doesn't it have to be something old browsers will ignore rather than misinterpret or fail to parse? The 3rd party CSS tooling can pick whatever syntax it wants because it is starting on a green field. Browser probably can't?

somehnacct3757 4y ago

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?