Linking original issue: #2124

Btw., would not it make sense to add more tests for ambiguous (especially with -sm=off) expressions like:

foo {
    0: 0 -red;  
    1: 1 - red; 
    2: -red * 2;
   @3: -red;

    &-bar@{3} {x: y}
}

I was confident, but -red * 2; really failed. So, do not merge yet.

It's just also similar quite not always predictable story with hex values, for example. So I'm just a bit concerned of more side-effects this could add.

Technically for -red * 2 I'd say it should fail as it can be considered as -webkit-fnord * 2. Thus it's not possible to decide if -red is actually a negated red or just a regular CSS identifier. It's tricky, obviously we do know there's no (and never will be?) such thing as -aqua in CSS, so we could probably assume it as an expression. On the other hand I suspect this would also mean that every identifier (in values/variables) beginning with - (e.g. -webkit-gradient) first has to be tried to be parsed as -color, and only if this fails it falls back to -ident, but this -> bad performance.

Thus I probably would left -red as-is (i.e. -red * 2 -> error) especially since for such ambiguous expressions a workaround will be as simple as red * -2 (or color(red) * -2 as it is now for #2124 in general).

P.S. e.g. just like -round(2.3) results in -round(2.3) currently, not -2.

Since color-0: 0 -red;compiles into color-0: 0 -red;, then I think -red * 2 should compile into -red * 2 instead of failing.

Never mind, identifier multiplied by number fails no matter what, so it is better to keep it that way. If it wants to be changed, it would be different issue anyway. So I will just add test you suggested without that.

Never mind, identifier multiplied by number fails no matter what, so it is better to keep it that way. If it wants to be changed, it would be different issue anyway.

Yep.