I've been using the contrast function for the first time and think it's buggy.
On this page, I find the following explanation:
contrast(@color1, @darkcolor, @lightcolor);
// outputs @darkcolor, when @color1 have more than 43% Luma
// if not it outputs @lightcolor
I have these 2 Colors:
@gBlue: #2196F3;
@gLightBlue: #03A9F4;
The first color has 60 Luma and the second one has 65 Luma. I expect Less to give me the @lightcolor for both colors. But that's not the result I'm getting!
Lessphp returns the @darkcolor for @gBlue and the @lightcolor for @gLightBlue.
Can anyone tell me why it does this? Is this a bug? Why don't I get the @lightcolor in both cases?

This doesn't seem to be a bug but rather a difference in terms of how the
contrastfunction works in Less.js, Less.PHP and lessphp (upto v0.4.0).In Less.js and Less.PHP, the contrast function decides on output color based on the
lumavalue of the reference color. Thelumavalues of the 2 colors given in question are less than 43% and hence they output the@lightcolor. You can check the output of the below code at Less2CSS.org (Online Less.js compiler) and Online Less.PHP compiler.The lessphp documentation however describes the
contrastfunction as follows: (looks like the doc is not updated with v0.5.0 changes)The
lightnessvalue for the first color is 54% while that for the second color is 48%. Because of this, lessphp outputs the@darkcolorwhen the first color is used as reference and@lightcolorwhen the second color is used as reference.You can try the below code at the Online lessphp compiler for v0.4.0 to see what I mean:
It could very easily be that lessphp introduced the
contrastfunction at first based onlightnessvalue before the official Less (the JS version) compiler implemented the same function but based it onlumainstead oflightnessvalue. The below statement could be found in the Less documentation: