-
We are moving to a themed implementation and as such are taking into use CSS var() function. Fomantic UI nicely provides a way to override so I can add: So my .../semantic-ui/src/themes/default/globals/site.variables:
And my .../semantic-ui/src/site/globals/site.variables:
Basically it allows the override of linkColor, but with linkHoverColor it tries to execute the functions on the var, even though I have an override and if it were the original executing first - there it was a hex value. If I comment out the linkHoverColor declaration in default, no error. I am not saying the less functions should work with var, of course they do not. My issue is that it seems to be having a mind of its own when interpreting the values - why is it using the var when I have an override and the override file itself is even after the var-less default... |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
Fixed by #2857 |
Beta Was this translation helpful? Give feedback.
-
Since mentioned in the issue - LESS evaluates variables again after they have been defined, so that is why it goes back to that Hover, then that means to override with var I need to declare the Hover option FIRST to eliminate that evaluation? |
Beta Was this translation helpful? Give feedback.
-
No, it always tries to evaluate, so the only solution is to make sure the darken() function is only called when the given value is really a color. If you want to test this: change @linkHoverColor : darken(saturate(@linkColor, 20), 15, relative); to @linkHoverColor : if(iscolor(@linkColor), darken(saturate(@linkColor, 20), 15, relative), @linkColor); inside the original themes/default/globals/site.variables and your custom theme using css variables should work. |
Beta Was this translation helpful? Give feedback.
Fixed by #2857
it is a nature of LESS to alway evaulate functions when a variable changes, so we added a check for a real color now and if not given, it uses the CSS variable.