> I want browsers to have first class Sass support.
We don't want that.
For example, CSS Custom Properties (CSS variables) are far more powerful than Sass variables. Plus you'd have two different implementations for how variables work—CSS variables work with the cascade but Sass variables don't. You can't have two fundamentally different methods for variables. That's a non-starter.
Pretty much all of the good stuff from preprocessors is going to be implemented in CSS (including conditional statements) relatively soon; we're just not there yet. But CSS Nesting is an important first step.
> Statistically, we do. Sass won the precprocessor wars and nearly every developer prefer SCSS variables over the var(--oh-god) that is CSS syntax.
This isn't about which preprocessor is the most popular; it's about the syntax that's going to be used for CSS that we're going to have to live with for a long time.
Look, best practices come and go. Table-based layouts, 960 grid [4], Dreamweaver, special hacks for IE6—we don't do those things any more. With all of the enhancements that have already been added to CSS (CSS Grid, Flexbox, Container Queries, :has() parent selector) and the ones coming—CSS nesting, style queries, conditional, new/better color spaces—using Sass will seem as old-school as including jQuery in every project in a few years.
To quote Denzel Washington's character in the movie Training Day: "We don't roll that way any more." [5]
If you want to go on using Sass, then nothing changes for you; you can even use custom properties in your Sass files. It's not an all or nothing situation.
> How are they more powerful? Does that offset their downside?
Seriously?
There's no functional downside compared to the alternative. The syntax isn't bad once you understand what's going on, but that's subjective anyway. Even if you don't love the syntax, the functionality they enable for developers more than makes up for that.
Sass variables are just static placeholders for values; they're just a step above doing a search and replace in an editor. Very handy when Sass was developed 16 years ago, but very limiting today.
The real question can the dynamic web experiences people come to expect be done only using Sass variables? Are taking full advantage of everything the web platform has to offer by only using Sass variables? The answer is no in both cases.
- they're not part of the DOM and they can't be accessed via JavaScript
- they can't be changed at runtime, such as responding to media queries or other state changes
- can't be used for passing values to and from web components
There are dozens of articles about why custom properties are superior to preprocessor variables:
That preprocessor variables are compiled out of existence is a feature. There are certainly situations where Custom Properties are useful, but if you don’t need that power, then using something simpler or inlining them out of existence produces results that are faster to run, use less memory, and are almost always smaller to ship.
