Compilation of named colors results in hex values being used incorrectly in interpolations

[TedDriggs]

The variable declaration @myVariable: red; recognizes that it contains a color, which is useful. However, on compilation div { color: @myVariable; } is compiled to:

div { 
    color: #ff0000;
}

instead of

div {
    color: red;
}

By itself, this isn't a huge problem, but it becomes one when attempting to use selector interpolation: .@{myVariable} { color: @myVariable; } becomes

.#ff0000 {
    color: #ff0000;
}

instead of

.red {
    color: red;
}

While it makes sense to parse the named color as a color rather than just a string, I'm not sure why the output wouldn't preserve the named color.

[seven-phases-max]

See #692.
It's more like a "legacy feature / indented behaviour" not really a bug.
The workaround for your particular case is to use: ~'red'or e('red') instead.

[seven-phases-max]

Regardless of above I actually also wonder myself what was the original purpose of this "immediate and unconditional" string to hex color conversion only for variables (I'm searching through old issues but didn't find the answer yet). Indeed, this all seems to be strange and confusing:

you-have-to-remember-when-its-converted-and-when-its-not {
    @tomato: tomato;
    color:   tomato;         // -> tomato
    color:  @tomato;         // -> #ff6347
    color: (@tomato + #111); // OK
    color:  (tomato + #111); // Error
    // etc.
}

It does not look like something that fits "Today's LESS" naturally. So, perhaps it is a good time to reconsider this behaviour.

---

Update: I found the corresponding issue (#289) and commits around it.
Well, yes, it's still looks questionable (like "introduced several minor issues here and there in favour of syntaxic sugar"):

1. The answer for Can't use color function on variable with named color #289 could be just: @alt_color: lighten(color(@main_color), 10%);
2. And if we really still need this automatic conversion for such function calls it would make sense to move this conversion from variable definition to somewhere near the function call/evaluation itself or so. Though I don't know how complicated it may be to implement.

[lukeapage]

its really difficult because some people also rely on the fact it is turned into hex.

in your example, it is like that because less is lazy - prop: red is essentially detected as not needing processing and is untouched - it never becomes a colour in the ast.

I'd support changing this to remember what it was encoded as and use that or default to hex (this is what transparent does) as long as we have a function to get to hex or a colour code.

[seven-phases-max]

I'd support changing this to remember what it was encoded as and use that or default to hex (this is what transparent does) as long as we have a function to get to hex or a colour code.

I see, yes that makes sense (especially if we already have more consistent transparent as reference). So to summarize:

new behaviour {
    @wheat:  wheat;
    color:   wheat;           // -> wheat (1)
    color:  @wheat;           // -> wheat (2)
    color: ( wheat + #111);   // Error    (3)
    color: (@wheat + #111);   // OK       (4)
    color:   spin( wheat, 5); // OK       (5)
    color:   spin(@wheat, 5); // OK       (6)
}

[seven-phases-max]

Updated: summary of #1604 changes moved to #1604 itself.

[TedDriggs]

Why is the named color not used with the --compress option? Introducing semantic changes between the normal and minified output seems like it will cause bugs that are hard to diagnose.

[seven-phases-max]

Why is the named color not used with the --compress option?

Only because I tried to keep the changes as minimal as possible (and I just did not see how bad it could be before I wrote the summary :). Of course I'll change this as soon as we're agree it's not acceptable.

[seven-phases-max]

--compress option

Fixed with later commits to #1604

[lukeapage]

Fixed in 2.0 branch