Confirmed Color variations can break when using LESS functions

[willl]

Affected version

2.3 RC2

Not a super common one, but if you're using a color variation with a LESS function like below:

xf-intensify(@xf-paletteColor3, 87%)

Variations for things like the select dropdown icon BG will break and instead load the default black icon BG.

Tested this with that value against #FFFFFF in the paletteNeutral3 value. #FFFFFF works, the function does not.

 

[Jeremy P]

A bit confused here. I've set paletteNeutral3 to #FFFFFF and added the following to extra.less:

.p-pageWrapper
{
    background-color: xf-intensify(@xf-paletteColor3, 87%);
}

The background color is evaluated as expected, where xf-intensify is darkening the color by 87% on the light variation and lightening the color by 87% on the dark variation. In both cases the end result is either black or white, matching the native LESS behavior and the behavior of XF 2.2.

The select gadget also seems to inherit the text color as expected in either case. Do let me know if I am misunderstanding something.

 

[willl]

Apologies if I was unclear; Screenshots are here to illustrate.



As you can see, I'm using xf-intensify to set the paletteNeutral colors based on paletteColor3 (which is just a straight RGB hex value).

This works fine except in one instance that I've found - select boxes and the BG image to set the dropdown indicator icon art:



As you can see, it's defaulting to black here.

If I set paletteNeutral3 to a standard hex value - like #ffffff - it'll then render properly..

 

[Jeremy P]

In the default style, the select icon color follows this chain (via core_input.less line 152):

@xf-input--color => @xf-inputTextColor => @xf-textColor => @xf-paletteNeutral3

So it is expected that it will ultimately match the @xf-paletteNeutral3 color. Your @xf-paletteNeutral3 color is xf-intensify(@xf-paletteColor3, 87%), which evaluates to hsl(210, 9%, 9%), so I'm assuming your @xf-paletteColor3 is hsl(210, 9%, 96%) (or the equivalent RGB/hex value)?

The real mystery to me is why the text of the selects is white, as they should inherit from @xf-input--color via the same chain. Do let me know if I'm being dense, or feel free to DM me a style XML/archive and I'll see what's going on.

 

[Jeremy P]

To follow that up a little, a simple test of setting @xf-paletteColor3 to hsl(0, 80%, 40%) and @xf-paletteNeutral3 to xf-intensify(@xf-paletteColor3, 10%) works as expected. Both the select text and icon have the color hsl(0, 80%, 30%).

Spoiler: Settings

Spoiler: Result

 

[willl]

@Jeremy P Ok, I've got even more for you here now after testing with your values and adjusting a bit..

Taking the values you have above, change paletteNeutral3 to xf-intensify(@xf-paletteColor3, 40%)



So, you get a nice low-saturation coral there.. However, when it renders on the front-end:



If you change it to just 20% on the intensify instead of 40%, you get this:





So for whatever reason it's changing the color values improperly with the xf-intensify JUST in the context of that SVG.

 

[Jeremy P]

Thank you, I finally see what's going on here now. I had to change around a few more style properties to reproduce the issue, namely the alternate variation of @xf-textColor which actually pulls from @xf-paletteNeutral1 instead, at least on the default style (which was not properly relying on xf-intensify/xf-diminish in my earlier tests).

In any case, the color for the icon tries to reference CSS variables that it doesn't have access to, which causes the functions to be evaluated as if it were always on the light variation (darkening instead of lightening in the case of xf-intensify).