Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I assume that the requirements for a browser implementation are more strict than for existing pre-processors such as Sass because 1) the performance budget is much more limited for interactive use compared to pre-processing and 2) browsers need to handle adversarial inputs gracefully. Are there any other reasons?


One potential reason is, SCSS only needs one implementation, and whatever that implementation does is SCSS. If you write `color:hover { ... }` it doesn't really matter whether SCSS happens to parse that as a `color: hover` followed by an illegal `{` token or if it happens to parse it as a nested selector; whichever the parser chooses is fine. But in a standard, with multiple implementations, you need to strictly resolve all ambiguities in the spec so that all implementations parse CSS the same way; just avoiding ambiguities in the grammar is by far the easiest way to achieve that.

Plus, different ways of implementing a parser could have different ways of resolving ambiguities. Maybe parsing `color:hover {}` as a selector happens to be super easy in Firefox's existing parser, but would require a rewrite of Chromium's parser, for example.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: