I think the question that's not answered clearly is: why can Sass parse it, but browsers can't?
It says: "If they see a sequence like element:pseudo, they’ll parse the entire style rule as if it were a property: value declaration.", but why can't the parser be modified to work like Sass parser?
Maybe it's obvious for someone who has deep parser knowledge, but for someone who only has a superficial knowledge, this is not clear. If Sass can transform .sass into .css, what's stopping Chrome from embedding the full sass software and preprocessing all css files with it, *if really wanted too*? While not ideal for obvious reasons, what I mean is: it seems to definitely be possible to do. Does this all just boil down to "we don't want to have the work of rewritting the CSS parser"?
I may be wrong, but I think it's a matter of complexity and speed. An efficient parser knows exactly what it is reading just by checking the next following word (token) and can act before it even reads the whole thing. Sass uses an "infinite lookahead" algorithm that makes it way slower (maybe doesn't matter for 1 file, it does for hundreds). With sass the parsing is made only when compiling the app, so it can afford the extra processing. On browsers, specially mobile, it can become a problem if you need to do it on all css of all pages.
An example that I think it's easy to understand: suppose you are reading a csv string of numbers that can be in base 10 or base 2.
Option a is something like "32, 101b, 101" (aka binary numbers have a "b" suffix, decimal numbers don't)
Option b is the same but the "b" is a prefix "32, b101, 101"
Now think that you can only "see" one character at a time, so you see "3", then "2", then "," and so on. Which of the two options is more efficient to parse?
The answer is option b. With option a you could read a sequence of millions of 1/0 digits but you don't know if it's binary or decimal until you read the final "b" or a "," (or end of file) so you can't do anything but remember all the digits until the end, when you can finally do something with the number. With option b you know in advance if it's going to be decimal or integer (whether you receive a "b" or directly a digit) so you can do all the optimizations right away before even start reading the number!
It's not a matter of whether it can be done or not (of course it can) but the complexity and slowness it can become.
> I think the question that's not answered clearly is: why can Sass parse it, but browsers can't?
I'm tired but here goes…
Parsing the proposed syntax isn't the real problem; it's parsing plus executing the selectors. Long story short: CSS is programming language that uses a JIT compiler to render CSS.
Sass doesn't run anything; it just transforms one text format into another text format; it's the browser runs the CSS.
Compared to what's required for CSS to run inside of a browser, interface with HTML, JavaScript and SVG (for starters), the Sass parser is trivial in comparison.
> Does this all just boil down to "we don't want to have the work of rewritting the CSS parser"?
Seriously, that's a non-starter for a code base the size and complexity of a browser engine. Not to mention it could mean throwing away years of work on these browser engines.
It's way too late for that… Chrome already has option 3 implemented; to rewrite something would delay this by… a few months? Maybe a year?
Think about it: should Apple, Google, Mozilla, Microsoft, Igalia rewrite code that's already running successfully for billions of users to accommodate whiney developers, many of whom are going to keep using Sass anyway, no matter what they do?
I doubt any of us, if we were leading these teams, would think rewriting major portions of the browser engines makes any kind of sense at this point.
SASS only really cares about CSS compatibility with valid CSS, and won’t compile invalid CSS
Browsers handle CSS in a way that invalid CSS is ignored. This way, when you add new syntax to CSS, older parsers will ignore just the parts it doesn’t understand, and most (or all of the developer is careful) of the page will will be styled correctly
So in short, browsers have to make invalid CSS work too
It does not matter if the browser can’t do it. Make it do it.
There’s no point in supporting nesting if the solution is worse than the options we have right now.
The vast majority of people would rather stick with preprocessors than deal with shit syntax.
If they implement a shitty syntax because of browser limitations they don’t want to fix. People will just use pre processors.
So it’s not about reading or not reading the article. It’s the fact that the options are shit and unless they do syntax similar to what we do now they should abandon trying to support nesting.
