Fixed Nested color functions cause template errors in 2.3 RC4

willl

Well-known member
Affected version
2.3 RC4
Got 2 new ones with color functions here.

When nesting color functions, it can cause errors when compiling the LESS. Got a couple examples:

Less:
box-shadow: 0 4px 15px 0 fade(shade(darken(@xf-pageBg, 20%), 40%), 20%);

If I remove - for example - the shade function, it'll end up coming out fine.

@xf-pageBg is just #fafbff - also tested with an rgb value, same issue.

Additionally, this also applies to inheritance from multiple style properties.

1719344682956.webp

In this case, the border color is..
Less:
xf-intensify(@xf-contentHighlightBg, 6%)
@xf-contentHighlightBg is just referencing @xf-paletteColor3, which.. Ok, bear with me, is..
Less:
tint(@xf-paletteColor2, 2%)
PC2 is
Less:
tint(@xf-paletteColor1, 5%)

..and PC1 is #313742.

It's a rather extreme case, but has been a part of our iO styles for a long time with no issues before.

EDIT: Turns out this also just applies to the shade function itself; Same "The first argument to mix must be a color index" error.

1719345195904.webp
 
This is sorted for the next release, but do note that tint (and to a greater extent mix) are evaluated a bit differently when variations are enabled. With variations disabled, the color transformations are evaluated on the server in RGB mode the same as before. With variations enabled, the color transformations are evaluated in the browser in HSL mode (by necessity).
 
I wonder if this is the same problem I had when trying to nest more than two color functions. Nesting two would work, but any third function in the nest would prevent it from working.
 
Back
Top Bottom