less mixin name is evaluated to colour/color

Question

I have a less file to define a bunch of colours/color. Each class name contains the name of the relevant colour, such as .colourOrange{..} or .colourBorderOrange{..} or navLeftButtOrange{..}.

To make this simple I have a mixin that uses a parameter name: colour, and uses this to name the classes thus:

.completeColour(@colourName, @col) {
.colour@{colourName}{
    …
}
.colourBorder@{colourName}{
   …
}
.leftNavButt@{colourName}{

….. } }

The problem is this the names of the classes are being evaluated to the relevant colour. So instead of getting .leftNavButtOrange{} I get .leftNavButt#ffa500{} in the resulting CSS

Is there a way to stop this with a compiler argument or something. Basically I don't want the parameter to be evaluated, read but not evaluated. Can I do this with a compiler argument or do I need to change the names so they don't match a color such as myAppOrange or something.

Answer 1

This is a legacy feature of Less. For the time being, one of the below work-around solutions could be used to overcome this color name to hex code conversion.

.completeColour(~"Orange",1);

or

.completeColour(e("Orange"),1);

Both the options explicitly tell the compiler that the value being passed is a String and not a Color and hence Less compiler would not convert it to the corresponding hex code.

Sources:

1. Less GitHub - how to avoid color name be translated into color value?
2. Less GitHub - Compilation of named colors results in hex values being used incorrectly in interpolations

Update: Starting from version 2.0.0, this color name to hex code conversion would not happen if the color is mentioned explicitly as a name and has no other color based operations on it. Version 2.0.0 is currently in beta mode.

(Official Update: V2 Upgrade Guide | Original Source: More consistent named color variables).