Hacker News Reader

Comment by mrcartmeneses | Hacker News Reader

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

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.

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

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.

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 [2] https://developer.chrome.com/blog/help-css-nesting/#:~:text=...

Reply on news.ycombinator.com