Skip to content
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

Lists + calc() breaks lookups for mixin-generated maps #3393

Closed
zaquest opened this issue Apr 28, 2019 · 3 comments
Closed

Lists + calc() breaks lookups for mixin-generated maps #3393

zaquest opened this issue Apr 28, 2019 · 3 comments
Labels

Comments

@zaquest
Copy link
Contributor

zaquest commented Apr 28, 2019

As the title suggests using a variable containing a list and calc() breaks maps that were generated by calling a mixin and saving the result in a variable.
Below is a minimal example I was able to come up with.

@textClasses: .h1, .h2, .h3;

@alias: @textClasses; // uncommenting this breaks things
// @{textClasses} { color: white; } // or this

// calc() is involved too, commenting this make the style compile again
div { width: calc(100px * 2); }

.mk-map() {
  text: white;
  background: black;
}

@p: .mk-map();
h1 { color: @p[text]; }

Trying to compile it results in SyntaxError: Could not evaluate variable call @p.

Less version 3.9.0

Is it a bug? Or am I missing something?

@zaquest
Copy link
Contributor Author

zaquest commented Apr 28, 2019

Seems like it doesn't matter if the variable contains a list or something else. For example the following doesn't work either:

@a: 10;
h2 { width: unit(@a, px); } // uncommenting this breaks the stylesheet

// calc() is involved somehow too, commenting this make the style compile
div { width: calc(100px * 2); }

.mk-map() {
  text: white;
  background: black;
}

@p: .mk-map();
h1 { color: @p[text]; }

@rgroothuijsen
Copy link
Contributor

rgroothuijsen commented Apr 28, 2020

Curiously, if you reverse the two halves, it doesn't throw an error. What appears to be the case is that the calculation causes Less to become stuck in calculation mode, which causes subsequent variables to be wrongly evaluated.

Edit: the likely culprit

@zaquest
Copy link
Contributor Author

zaquest commented Apr 29, 2020

#3493 seems to solve the issue. Thank you!

@zaquest zaquest closed this as completed Apr 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants