4 ms·
There are indeed significant differences. The main one is that Sass is, basically, a "code generator". It's a sort of template language that generates CSS code
by genezeta 5y ago
There are indeed significant differences.
The main one is that Sass is, basically, a "code generator". It's a sort of template language that generates CSS code. And so, a "Sass-if" works at code generation time, that is, when you execute the Sass command:
sass-if (some logical condition) {
<some CSS code>
} else {
<some other CSS code>
}
Depending on the condition and at compile time, sass would spit out the first block of code or the second. The condition is, basically, a calculated expression that applies to values and variables available at compile time.
Then -after deployment and when a client visits your website- that CSS code is served to the client. Clients are varied and so CSS wants to have its own if structure that applies at runtime. The conditions generally would check the current runtime conditions (i.e. is this running on a large screen? is this browser in vertical orientation? etc)
css-if (some condition pertaining this specific current browser) {
<some CSS code>
} else {
<some other CSS code>
}
So, yes, they are clearly and necessarily different, both in scope and usage. And so you'd generally need both if because they do different things. And that where the problem arises, because if you want to have both, their syntaxes need to be distinguishable.
- veidelis 5y agoVery good description, thank you. One thing I don't understand is why not: 1) change Sass implementation to support "sass-if" and backport these changes to some older versions if necessary 2) upgrade the Sass's version and do a mass replace which sounds kind-of simple 3) use CSS's if happily
- genezeta 5y agoYeah, personally that's the option I would choose too. It should fall on Sass to change whatever they may need to. It's not completely "kind-of simple" though, as there is, potentially, a fair amount of code written with Sass in currently running projects. It is a cost to consider. Also, there have been some precedents in the JavaScript community, mainly with Mootools -an old library, mostly irrelevant today but with some existing code still running in the wild- and the name of a couple of methods such as includes and flatten. The thing is that TC39 really pushes for "not breaking anything at all", and by proximity the CSS community seems to have some people with a similar opinion.