Fixed LESS lighten/darken functions no longer work as expected

X

Xon

Well-known member
Affected version
2.3.0
Code: 
<xf:set var="$color" value="rgb(173, 216, 230)"/>
<xf:set var="$lighen" value="{{ parse_less_color("lighten({$color}, 30%)") }}"/>
<xf:set var="$darken" value="{{ parse_less_color("darken({$color}, 30%)") }}"/>
<xf:set var="$background" value="{{ parse_less_color('@xf-contentBg') }}"/>
{{ dump($color) }}
{{ dump($lighen) }}
{{ dump($darken) }}
{{ dump($background) }}
In XF2.2, this outputs:
Code: 
"rgb(173, 216, 230)"
"#ffffff"
"#3a9fc0"
"#fefefe"
In XF2.3, this outputs:
Code: 
^ "rgb(173, 216, 230)"
^ "hsl(195,53%,calc(79%+30%))"
^ "hsl(195,53%,calc(79%-30%))"
^ "hsl(var(--xf-contentBg))"

Which is unexpected as it isn't returning the actual color code, which breaks being able to work with the hexadecimal color :(
 
Last edited:
Yes, that’s the basis of how the variations system works and opens doors for future functionality as well. We can potentially provide an opt-out here but I guess I’m not too clear on the exact use case. It doesn’t seem any more or less expected that Less converted them into hex values to begin with.

The opt-out would also likely break interoperability with style properties and variations.

You can get an explicit variation value using {{ property_variation('contentBg', 'default') }}.
 
It is somewhat of a niche use-case, but it is related to my SV/SvgTemplate add-on. Which can need to render LESS fragments into an SVG's inline CSS (ie not depend on XF's CSS being loaded a view time) and then render to a PNG for client-side performance reasons.
 
Ah ok, we have a vaguely similar use case for another bug actually with the select input dropdown SVG icon, so I’ll find a way to accommodate that.
 
There is an actual bug with parse_less_color returning a non-hexadecimal color;
HTML: 
<meta name="theme-color" content="{{ parse_less_color(property_variation('metaThemeColor', 'default')) }}" />

This will produce results which aren't accepted from a number of external embedding targets (facebook/discord/etc) that expect an hexadecimal color code, not css variables.
 
This is a somewhat older bug, but still seems relevant:

{{ parse_less_color(property_variation('textColor', 'alternate')) }} does not return a hex color with default style.
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.3.8).

Change log:
Always coerce `parse_less_color` template function to hex for non-variable values
Click to expand...
There may be a delay before changes are rolled out to the XenForo Community.
 
Note that the psuedo-variable shorthand (@xf-contentBg) is resolved to a CSS variable when the style variation is variable (the default when variations are enabled), which means it cannot be parsed to a hex color:

HTML: 
{{ parse_less_color('@xf-contentBg') }}
 
Back
Top Bottom