Variables in background shorthand produce an error

[thany]

This works:

$clock-size: 4.2rem;
.clock {
  background: url(/includes/image/clocks.svg) no-repeat 0 0;
  background-size: ($clock-size * 13) $clock-size;
}

This doesn't:

$clock-size: 4.2rem;
.clock {
  background: url(/includes/image/clocks.svg) no-repeat 0 0 / ($clock-size * 13) $clock-size;
}

It'll produce this error:

0/rem isn't a valid CSS value.

Which is a weird error to begin with. Why would sass output css that can never be valid for anything, especially if the scss is perfectly valid?...

As you can see, the current workaround is to use the longhand for background-size, but I'd prefer to be able to realiably use the shorthand as well.

I'm using SASS 3.4.9, Gem 2.4.5, Ruby 2.1.3p242 x64, and Windows 7 x64.

[Arcovion]

This is mentioned in the docs:

If you want to use variables along with a plain CSS /, you can use #{} to insert them.

$clock-size: 4.2rem;
.clock {
  background: url(/includes/image/clocks.svg) no-repeat 0 0 / #{$clock-size * 13} $clock-size;
}

[thany]

Consider this a feature request then ;)

It looks like SASS should be able to figure this out without me having to tell it explicitly to keep its hands off, so to speak. Also, the fact that it spews out syntactically incorrect CSS should be an indication for itself this it has misinterpreted something.

[cimmanon]

Not sure that I agree that "Sass should know". Consider the following:

$font-size: 100%;
$multiplier: 15px;

.foo {
    font: $font-size / $multiplier sans-serif;
}

How is Sass supposed to know that you mean here? To output 100%/15px would be wrong if you actually wanted division (and you can't divide because the units are incompatible). Similarly, if the property was font-size, rather than font, font-size: 100%/15px would be invalid.

Sass doesn't know what's "valid" for any given property, it only knows what patterns are valid. This allows it to be future proof. You don't need to upgrade Sass just because a new property was added to the spec or made up by the browser vendors (hell, I make up new ones when I am doing debugging on Sassmeister).

[KittyGiraudel]

It looks like SASS should be able to figure this out without me having to tell it explicitly to keep its hands off, so to speak.

Allow me to disagree. a / b is a division. If it is not meant to be one, it is your responsibility to tell Sass about it.

[lolmaus]

@hugogiraudel, here's a counter-argument: Sass aims not to derive from CSS standard, and CSS does use / as part of a property.

[thany]

Here's another counter-argument: using / for divisions may have been a bad choice. Too late now, so we need to deal with it.

But anyhow, SASS is outputting syntactically incorrect css in my example. That's a whole different story from invalid css for a given propery.

[cimmanon]

@thany which is it now? Sass is throwing an error because you're doing something invalid (division with incompatible units) or Sass is generating invalid CSS? It can't be doing both.

[thany]

It's throwing an error were none is neccesary. And it's trying to generate syntactically invalid css.

I'm saying that if it turns out an expression like in my example produces css, maybe SASS should try handling the / not as a division but as part of a css value.

[chriseppstein]

SCSS is a CSS superset. This means that Sass will treat the / character exactly how CSS would treat it as long as you haven't introduced any Sass constructs into it. That means that Sass DOES NOT treat / as division here:

.clock {
  background: url(/includes/image/clocks.svg) no-repeat 0 0 / 70 15;
}

Now, the question is, what should Sass do if you're using SassScript in this context. And here we have decided that once you start using SassScript the benefit of letting / be devision in SassScript expressions outweighs the use case for the one property that using slash as a delimiter. So we have documented that if you start using SassScript here, you have to do a little extra legwork to get the slash to not be division.

[thany]

What Sass should do is not try to generate invalid css. If the Sass is syntactically valid, it should never spew out syntactically incorrect css no matter what. Invalid css is one thing, byt syntactically invalid css shouldn't happen in this case.

[lolmaus]

What do you consider to be "semantically valid Sass"? Is it what you expect it to be?

From my point of view, "syntactically valid Sass" is what @nex3 and @chriseppstein determine to be.

[thany]

Syntactically valid is what the compiler can parse and work with. But that on its turn, is trying to produce syntactically invalid css, as per the error message. Sure, 0/rem isn't valid syntax for either, but I never typed that. It's merely the result of how the / is handled and how Sass handles unitless values icw values with unit.

[thany]

One could say:

• In all cases, hands off the / operator.
• ...except when hands-off is going to produce invalid css, for example when it's enclosed in ( and ).

And many folks already consider it "good practice" to enclose all inline calculation in braces, so such a change wouldn't change much for the worse.

[cimmanon]

@thany Sass isn't generating invalid CSS, it is raising an error telling you that you f'ed up. How the division operator behaves is well documented.

http://sass-lang.com/documentation/file.SASS_REFERENCE.html#division-and-slash

[thany]

Well documented or not, it's still confusing. I didn't raise this issue because it's crystal clear, did I?

Plus, it doesn't change how 0/1rem tries to generate a value of 0/rem. That's just silly and not useful for anything ever, no matter how mathematically correct it might be.

[thany]

So will this be fixed at some point or not? I'm running into this again, by writing down something that is completely sensible:

background: url(/includes/image/placeholder.png) no-repeat 50% 50% / (2 * $something) (4 * $something);

It says:

3.861%/rem isn't a valid CSS value.

I know this, and apparently Sass knows this as well. So why is it trying to ouput something it knows is going to be invalid if it did??

A silly workaround:

background: url(/includes/image/placeholder.png) no-repeat 50% 50% #{'/'} (2 * $something) (4 * $something);

[nex3]

The issue is closed, indicating that the behavior won't be changed from how it currently works.

[thany]

I realize that, so I'm asking for reconsideration. Because, well, like I said, Sass trying to produce "1.234%/rem" as a value, and erroring on it, isn't useful.