Unquoted color names are confusing

with style: compressed, the replacement of some colornames to hex codes takes place even in map keys. This is unexpected if not a bug.

Example below compiles uncompressed, but gets a syntax error compressed.

Syntax error: Invalid CSS after “&.”: expected class name, was “#90ee90” on line 14 of demo.scss

(version 3.3.7)

$schemes: (
        lightgreen: (
                primary: rgb(30, 151, 64),
                secondary: rgb(149, 0, 70)
        )
);

a {
  text-decoration: none;
  color:  #999;
  @each $name, $spec in $schemes {
    &.#{$name} { color: map-get($spec, primary) }
  }
}

[nex3]

I’m not interested in changing the existing behavior. It does have some awkward edge-cases, but the underlying logic is clear and unambiguous—colors and strings are wholly separate types, and the implementation has license to treat all colors the same regardless of their literal format.

1 == '1'

This returns false. Sass does no type coercion in ==.

the v4 alpha commit here is about?

No. That commit is purely cosmetic; it makes colors more similar to their source definition in human-readable output formats, but it doesn’t change the language itself. In particular, in compressed mode, Sass will still choose the smallest possible format for a color. This may be behavior users are relying on, and I’m not willing to change it.

[barneycarroll]

@nex3 sorry, just reading back through the thread again - is this suggestion what the v4 alpha commit here is about?