sass wont let me use css min()

[saltnpixels]

I have css code like this:

--min: 250px;
width: min( var(--min), 100%);

Sass breaks with error:
Error: "var(--card-min)" is not a number for `min'

I think its trying to use some function called min and not css min. How can i tell it to not do this or ignore sass for this line?

[Awjin]

We need more information to help diagnose your problem. Which implementation of Sass are you using, and which version?

[saltnpixels]

Im using gulp-sass.
I switched to gulp-dart-sass and the issue went away. Although now output style of 'compact' wont work as the setting for compressing the sass...

[Awjin]

Dart Sass supports two output styles: https://sass-lang.com/documentation/cli/dart-sass#style.

[Ariane-B]

This was annoying me a lot (in Dart Sass 1.26.3), since it was making the use of CSS min/max functions really unreliable, so I created a Sass function to force the CSS functions. Use them if you'd like.

@function css-function( $function, $values... ) {
	@return 
		$function
		+ unquote( '(' )
		+ $values
		+ unquote( ')' )
	;
}

@function css-min( $values... ) {
	@return css-function( min, $values );
}

@function css-max( $values... ) {
	@return css-function( max, $values );
}

@function css-clamp( $values... ) {
	@return css-function( clamp, $values );
}

You might still need to use #{ } interpolation when using Sass variables and CSS variables combined with them though, in some cases, to make sure Sass parses them properly. So:

.my-selector {
  width: css-min( #{ $width-abs }, #{ $width-rel } );
}

[nex3]

This was annoying me a lot (in Dart Sass 1.26.3), since it was making the use of CSS min/max functions really unreliable,

Can you explain how the CSS min/max functions are unreliable in Dart Sass?

[Ariane-B]

It's not just Dart Sass. Libass does it as well. Dart Sass is a little less vulnerable, it will still try to use the Sass function when there is no reason to. Here's an example from my current project.

The following trips up Libsass since it tries to use the Sass max() function with incompatible units. Dart Sass handles it fine, though.

.subsection-menu {
  font-size: 0.85em; // fallback
  font-size: max( 0.85em, 16px );
}

The following, however, throws an error (incompatible units) with both Libsass and Dart Sass.

$font-size-small: 16px;

.subsection-menu {
  font-size: 0.85em; // fallback
  font-size: max( 0.85em, $font-size-small ); 
}

You might say I could just use the second version and interpolate $font-size-small. That would work. But interpolating all the time is annoying and my own function doesn't require that in most cases.

I also need to consider compatibility between compilers. Libsass tries to use the Sass function, interpolation or not, so there's just no way it'll work there.

At the moment, Dart Sass has a few annoyances (see this infuriating issue), so we can't fully switch yet.

Since CodeKit updated Libsass and added Dart Sass, all calculated numbers have had a whopping 10 decimal places, which I feel uselessly lengthens my final stylesheet and makes things uglier in the inspector. If 33.3333% and 33.3333333333% are still the same over 2000 pixels, why should I bloat up my stylesheet further?

I've strayed off-topic, but the gist of what I'm trying to say is: I've barely started using Dart Sass and I've already got those reasons not to fully trust it yet. So we probably shouldn't be coding stuff that Libsass won't also take for now.

[Awjin]

The following, however, throws an error (incompatible units) with both Libsass and Dart Sass.

$font-size-small: 16px;

.subsection-menu {
  font-size: 0.85em; // fallback
  font-size: max( 0.85em, $font-size-small ); 
}

You might say I could just use the second version and interpolate $font-size-small. That would work. But interpolating all the time is annoying and my own function doesn't require that in most cases.

Let’s consider the alternative behavior and see what happens if Sass does not throw an error for incompatible numbers, but instead silently generates max(0.85em, 16px). This would cause unexpected behaviors, e.g.:

• Sass users relying on max() to output a number would instead receive CSS code that might not work on older browsers.
• We would not be able to use max() with other Sass math functions, since they expect to operate on numbers.

I understand it’s frustrating that max() doesn't do what you want in this case, but the alternative behavior would be a lot more frustrating to other people in a much harder-to-debug way.

Looping back to your original problem, since the call to max() contains a Sass variable, it gets parsed as the Sass max() function. To ensure that CSS max() is called instead, interpolate the variable:

.subsection-menu {
  font-size: max(0.85em, #{$font-size-small});
}

This has been implemented in DartSass for a couple years now, but not in LibSass. Here is the issue tracking CSS min/max support in Sass: #2378. Further, I would recommend using the built-in math module to make calling Sass’s max() function more explicit.

At the moment, Dart Sass has a few annoyances (see this infuriating issue), so we can't fully switch yet.

Implementing new behavior takes a lot of work, and the Sass team has limited bandwidth. With this sort of change, we need to consider how CodeKit’s use-case fits into a larger Sass ecosystem. If you would like to drive discussion on this issue and explore possible solutions, please feel free to do so.

Since CodeKit updated Libsass and added Dart Sass, all calculated numbers have had a whopping 10 decimal places, which I feel uselessly lengthens my final stylesheet and makes things uglier in the inspector. If 33.3333% and 33.3333333333% are still the same over 2000 pixels, why should I bloat up my stylesheet further?

We increased the precision to 10 digits, because we had many real user reports that five decimal places was such low precision that it was regularly causing rendering glitches. 10 digits provides enough precision for all browsers without causing too much bloat.

And, RE: LibSass and Dart Sass—

I also need to consider compatibility between compilers. Libsass tries to use the Sass function, interpolation or not, so there's just no way it'll work there.
[…]
I've strayed off-topic, but the gist of what I'm trying to say is: I've barely started using Dart Sass and I've already got those reasons not to fully trust it yet. So we probably shouldn't be coding stuff that Libsass won't also take for now.

We're doing our best to defragment Sass and are hoping LibSass will catch up to Dart Sass's features.

[Ariane-B]

• Sass users relying on max() to output a number would instead receive CSS code that might not work on older browsers.

• We would not be able to use max() with other Sass math functions, since they expect to operate on numbers.

I understand your concerns for backward compatibility, but could there not be another solution? In the future, it's very realistic to think that the use of CSS min will greatly surpass the use of Sass min. I'm just brainstorming here and I may be missing something, but here are a few ideas I can think of:

• Slowly deprecate the old functions that overlap with CSS and ask people to use math.min instead.
• Other Sass math functions could explicitly call math.max().
• Anytime there are incompatible units, output the CSS function instead. In other words, change the trigger for Sass's function from "there is at least one non-interpolated variable" to "after interpolating all variables, there are compatible units". That could be achieved by always parsing the variable's value before running it through the normal code. If it's incompatible units, display the standard CSS function. If it's compatible units, run it through math.min. After all, what's the point of a variable and its exact value extrapolated not giving the same result? And CSS min(10px, 16px) should be simplified to 10px by Sass anyway. Anyway, if people make a mistake and end up with an unintended CSS min() and they need to support old browsers, their QA process should absolutely check those browsers and notice. It's kind of similar to accidentally setting the font size to 2px instead of 2em. It's a mistake from the person who wrote the code, and I'm not sure it's a good idea for a preprocessor to prioritize catering to that.
• Any of the above, but also provide an option to keep the legacy behaviour of using Sass min by default.
• Any of the above, but also throw a warning whenever compiling something that used to try to use math.max() (and would've thrown an error) that ended up as a CSS math function. That warning could be silenced with an option or special flag in the entry point file.

This has been implemented in DartSass for a couple years now, but not in LibSass. Here is the issue tracking CSS min/max support in Sass: #2378. Further, I would recommend using the built-in math module to make calling Sass’s max() function more explicit.

I would like to eventually make that move (once the Libsass compatibility issues are behind us) and move to @use and such. Would importing my stylesheets with @use prevent me from unwillingly using Sass's max function in the example I described? I would probably not import the math module, considering I have never in my life had to use those functions. Would then using max() in my code necessarily print the CSS function if the units aren't the same?

If you would like to drive discussion on this issue and explore possible solutions, please feel free to do so.

What do you mean? There's already an issue on the Dart Sass tracker. Would you like me to explain why I think deleting the file is counter-productive in most cases? What do you expect from me?

We increased the precision to 10 digits, because we had many real user reports that five decimal places was such low precision that it was regularly causing rendering glitches. 10 digits provides enough precision for all browsers without causing too much bloat.

I understood that argument already, and I read your response to a previous issue regarding that. I understand that there are some real edge cases where a high level of precision is required. But that has never happened to me. What if I do consider 10 digits too much bloat? I would really appreciate it if there was once again an option to decide for myself how much precision I consider relevant. Sure, you can make 10 the default. I understand the reasoning that precision should be more important than a few bytes in a file. But it would be nice if I could reduce it in the projects where I don't need that kind of extremely precise number.

We're doing our best to defragment Sass and are hoping LibSass will catch up to Dart Sass's features.

I greatly appreciate the effort. :) I'm looking forward to that day.

[nex3]

I understand your concerns for backward compatibility, but could there not be another solution? In the future, it's very realistic to think that the use of CSS min will greatly surpass the use of Sass min. I'm just brainstorming here and I may be missing something, but here are a few ideas I can think of:

• Slowly deprecate the old functions that overlap with CSS and ask people to use math.min instead.

This is indeed the plan. However, we can't actively deprecate the existing global syntax until LibSass is compatible with the module-scoped syntax, because otherwise authors would have no way of writing stylesheets that run warning-free in both implementations.

• Other Sass math functions could explicitly call math.max().

I'm not sure what you mean by this.

• Anytime there are incompatible units, output the CSS function instead. In other words, change the trigger for Sass's function from "there is at least one non-interpolated variable" to "after interpolating all variables, there are compatible units". That could be achieved by always parsing the variable's value before running it through the normal code. If it's incompatible units, display the standard CSS function. If it's compatible units, run it through math.min. After all, what's the point of a variable and its exact value extrapolated not giving the same result? And CSS min(10px, 16px) should be simplified to 10px by Sass anyway. Anyway, if people make a mistake and end up with an unintended CSS min() and they need to support old browsers, their QA process should absolutely check those browsers and notice. It's kind of similar to accidentally setting the font size to 2px instead of 2em. It's a mistake from the person who wrote the code, and I'm not sure it's a good idea for a preprocessor to prioritize catering to that.

This is loosely the proposal described in #2186. However, in addition to being ferociously complex to design and implement, it's never going to be possible to use CSS math expressions like min() fully interchangeably with Sass numbers. Numbers ultimately need to be usable for all sorts of things that can't be deferred to the client, such as @if statements and color functions.

• Any of the above, but also provide an option to keep the legacy behaviour of using Sass min by default.

Sass never provides flags to change the behavior of the language. It's vitally important that a Sass stylesheet written in one environment be possible to share seamlessly with any other environment, regardless of its configuration.

• Any of the above, but also throw a warning whenever compiling something that used to try to use math.max() (and would've thrown an error) that ended up as a CSS math function. That warning could be silenced with an option or special flag in the entry point file.

This has the same problems as the above: users never want to have code that produces warnings, so the same Sass code is effectively allowed in one configuration and disallowed in another.

I would like to eventually make that move (once the Libsass compatibility issues are behind us) and move to @use and such. Would importing my stylesheets with @use prevent me from unwillingly using Sass's max function in the example I described? I would probably not import the math module, considering I have never in my life had to use those functions. Would then using max() in my code necessarily print the CSS function if the units aren't the same?

No, the behavior of the global max() won't change contextually based on which modules you @use. But as long as you only ever use interpolation with max(), you'll always get the plain-CSS function. It's not like max(0.85em, $font-size-small) is valid plain CSS anyway.

I understood that argument already, and I read your response to a previous issue regarding that. I understand that there are some real edge cases where a high level of precision is required. But that has never happened to me. What if I do consider 10 digits too much bloat? I would really appreciate it if there was once again an option to decide for myself how much precision I consider relevant. Sure, you can make 10 the default. I understand the reasoning that precision should be more important than a few bytes in a file. But it would be nice if I could reduce it in the projects where I don't need that kind of extremely precise number.

I recommend PostCSS for CSS-to-CSS transformations like setting a particular precision for your numbers.

[Ariane-B]

I see. Thanks for the thoughtful reply! It'll be interesting once only math.min() exists. I'm guessing that'll take a while, but it makes sense that it wouldn't be easy for the Libsass team to implement a completely different way of "importing" stylesheets.

As for #2186, I understand implementing the whole "super smart" math management is really complicated. But as a first step to that, would it be possible to just interpolate any variable that's about to be run through math.min() (by way of min()) before deciding whether the units are compatible or to just output the CSS as-is with the Sass variable auto-interpolated?

My understanding of the workings of the thing are rudimentary at best, but it seems to me that would be doable relatively simply for those three CSS functions for the time being. Or would that be a bad idea in the long run because of the cross-compiler compatibility problem?