Hacker News Reader

Comment by donatj | Hacker News Reader

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

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?

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

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

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.

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.

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.

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?

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.

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