4 ms·

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=...

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=...