-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSS min and max function calls that hold CSS variables fail with "Operation on an invalid type" #3777
Comments
can i work on this bug? |
@shindodkar I don't see why not! |
can I contribute to it ?? |
@GitsOfVivek @debmalya37 Anyone can do this at any time. @shindodkar asked about it March 31st, but nothing has been produced yet. |
One way to prevent having to do this several times in several places would be to, rather than creating a try / catch block within each function, would be to create an abstraction that outputs certain functions as-is. In other words, a number of functions have had try / catch blocks added within the function statement, and outputs the nodes as-is instead of throwing an error if it can't evaluate something, but that gets repetitive to add per function. A downside of doing this is that if the stylesheet author intended Less to evaluate the statement, and there is an error in the expression, rather than showing an error, it will just output the function. |
@GitsOfVivek I'm not sure what more can be said about it. |
Can I be assigned this @matthew-dean |
prop: clamp(10px, calc(100% - var(--some-var)), 100%); |
I have been pretty active on github for the last few days, I'll be quick in fixing this. |
thanks @matthew-dean |
Hey @matthew-dean I tried implementing the abstraction in the src/less/functions/number.js `function evaluateWithFallback(func, context) { export default {
}; the following test cases are failing: min(1, 4ex, 2pt) and max(5m, 3em); Your expertise in this matter would be highly appreciated. |
@Cyddharth-Gupta Can you start a draft PR I can look at? |
I'm guessing Less tries to eagerly normalize them to the same unit type? |
sure, will do that. |
@matthew-dean i created a Draft PR a couple of days ago, please have a look at it. |
|
@iChenLei the CI test that are failing are in accordance with the conversation with @matthew-dean , that's why Matthew asked me to start a draft PR, please go through the conversation above. |
@Cyddharth-Gupta it says you closed the PR? |
@matthew-dean my apologies, didn't get a reply for some days since I created the pr, so I thought it might not be an active issue. I will create a new one by tomorrow. |
Workaround: use string escaping x {
prop: e("min(100% - var(--some-var), 10px)");
} results in x {
prop: min(100% - var(--some-var), 10px);
} |
Same problem with other functions like pow: |
* Fixes issue less#3777 where using CSS custom property in an operation resulted in a parsing error.
* Improves CSS custom property initial value support, including nesting scenarios to better address issue less#3777.
To reproduce:
With strict units enabled, perform a
calc
-like expression inside amin
ormax
functionand use a CSS variable. E.g.
Current behavior:
Compiler will throw "Operation on an invalid type" error.
Expected behavior:
Compiler knows the arguments to
min
andmax
can becalc
-like and doesn't throw, but retains the arguments as-is.Environment information:
less
version: 4.1.3nodejs
version: 14operating system
: anyHaving dug around a bit, it appears that the root of the issue is the fact that
Operation
is visited and flattened before passing tomin
andmax
, which means thevar()
node trips the compiler error as it afaict does not implement anoperate
method.This problem can be avoided by setting
evalArgs : false
for both functions and performing custom lazy evaluation inside the functions themselves, where it can be wrapped in a try-catch and cause the function to go inert (and be treated as the CSS function proper) when incompatible types are present.The text was updated successfully, but these errors were encountered: