CSS has recently added many cool features, such as custom properties and new functions. While these features can simplify our work, they can also create interesting interaction problems with preprocessors such as Sass.

This article will explore the problems I encountered, solutions, and why I still think Sass is essential.

Error encountered

If you have used the new min() and max() functions, you may encounter an error message like this when handling different units: "Incompatible units: vh and em".

This is because Sass has its own min() function and ignores CSS's min() function . Furthermore, Sass cannot perform any calculations using values ??that have no fixed relationship between two units.

For example, there is a fixed relationship between cm and in units, so Sass can calculate the result of min(20in, 50cm) and will not report an error when used in the code.

The same is true for other units. For example, there is a fixed relationship between angle units: 1turn, 1rad, or 1grad is always calculated as the same deg value. Similarly, 1s is always 1000ms, 1kHz is always 1000Hz, 1dppx is always 96dpi, and 1in is always 96px. That's why Sass can convert between them and mix them in calculations and functions (such as its own min() function).

However, when there is no fixed relationship between these units (such as the previous examples of em and vh units), problems arise.

It's not just a different unit. Trying to use calc() min() will also result in an error. If I try a code like calc(20em 7px) I get an error that " calc(20em 7px) is not a number for min ".

Another problem arises when we want to use the result of a CSS variable or mathematical CSS function such as calc() , min() or max() ) in a CSS filter (e.g. invert() ).

In this case, we will receive a prompt that "`$color: 'var(--p, 0.85)' is not a valid color for invert".

The same problem occurs grayscale() : " $color: 'calc(.2 var(--d, .3))' is not a valid color for grayscale".

opacity() also causes the same problem: " $color: 'var(--p, 0.8)' is not a valid color for opacity".

However, other filter functions—including sepia() , blur() , drop-shadow() , brightness() , contrast() , and hue-rotate() — all work properly with CSS variables!

As it turns out, what happened is similar to min() and max() problems. Sass does not have built-in sepia() , blur() , drop-shadow() , brightness() , contrast() , hue-rotate() functions, but it does have its own grayscale() , invert() and opacity() functions, and their first argument is $color value. Since it cannot find the parameter, an error is thrown.

For the same reason, we also have trouble when trying to use CSS variables that list at least two hsl() or hsla() values.

On the other hand, color: hsl(9, var(--sl, 95%, 65%)) is a fully valid CSS and works fine without Sass.

The exact same thing happens to rgb() and rgba() functions.

Also, if we import Compass and try to use CSS variables inside linear-gradient() or radial-gradient() , even if we use variables inside conic-gradient() (if the browser supports it), we will also get another error.

This is because Compass comes with linear-gradient() and radial-gradient() functions, but conic-gradient() function has never been added.

The problem in all these cases stems from Sass or Compass having functions of the same name, and assuming these are the functions we intend to use in our code.

Oops!

Solution

The trick here is to remember that Sass is case sensitive, but CSS is not case sensitive .

This means we can write Min(20em, 50vh) which Sass will not recognize as its own min() function. No error is thrown, it is still valid CSS and works as expected. Similarly, writing HSL() / HSLA() / RGB() / RGBA() or Invert() can avoid the problems we had before.

As for gradients, I usually prefer linear-Gradient() and radial-Gradient() because it's closer to the SVG version, but it works fine with at least one capital letter in it.

Why?

Almost every time I post any Sass-related tweets, I'll be warned that now that with CSS variables, Sass shouldn't be used anymore. I want to solve this problem and explain why I disagree.

First, while I found CSS variables to be very useful and used in almost every aspect over the last three years, it is important to note that they come with performance costs and it can be painful to use the current DevTools to track where errors appear in calc() calculation maze. I try to avoid overuse them so as not to get stuck in a situation where the shortcomings of using them outweigh the benefits.

Generally speaking, if it works like a constant, does not change element-by-element or state-by-state (in which case a custom attribute is definitely the best option), or reduces the number of compiled CSS (solves duplicate issues created by prefixes), then I'll use a Sass variable.

Second, variables have always been a small part of the reason I use Sass. When I started using Sass in late 2012, it was mainly used for loops, which is a feature we still don't have in CSS at the moment. While I have moved part of the loop to the HTML preprocessor (because it reduces the generated code and avoids having to modify both HTML and CSS later), I still use Sass loops in many cases, such as generating a list of values, stop lists within gradient functions, point lists within polygon functions, transform lists, and so on.

(The following content is consistent with the original text, omitting duplicate parts to avoid redundancy)

The above is the detailed content of When Sass and New CSS Features Collide. For more information, please follow other related articles on the PHP Chinese website!