Use Dynamically Generated Classes as Mixins

[scottgit]

This request is similar (though does not seem to be exactly the same) to the closed issues of #617 and #1133. It is also related to #1325 (both there and here seeks to "use" what Jon there calls "non-existent" classes, so the solving of one may solve the other). (If I missed a more exact statement of the same issue, forgive me for posting this new one.)

In all the issues use cases are sought, which I hope to provide here. The goal is to be able to essentially do the following (though it really becomes more powerful when in a loop structure):

Dynamically build a class name (which we can do now):

.myClassBuilder(@classname) {
   .@{classname} { some-properties: some values;}
}

.myClassBuilder(myName);

/* Outputs */

.myName { some-properties: some values;}

Then use that class name as a mixin (which currently gives a .myName is undefined error):

.my .big > .long .selector + .string {
    .myName;
}

/* Outputs */

.my.big > .long .selector + .string { some-properties: some values;}

Now as to reasons "why" to do it:

1. Since LESS is designed to use classes as mixins, intuitively users expect it to work (this is evidenced by the links given in the following reasons).
2. One use case is seen in this StackOverflow question trying to dynamically generate font sizing. Note how the user expected it to work. Now Martin's answer given on that question is a good workaround for that case, but the workaround is still quite cumbersome compared to what the user wanted to do.
3. Another, perhaps more significant, use case is integrating with frameworks. In such a case, the framework may not be designed to make class properties accessible through a separate mixin like Martin advocated as a solution to the Support require('less').render(str, options) #2 problem. Further, the user of a framework like Bootstrap may not even know or understand the underlying code of Bootstrap itself, and not realize which classes are or are not dynamically generated. This is illustrated some in my answer on this StackOverflow question, which is the same one noted in issue :extend to extend dynamically generated classes? #1325. In such a case again, the expectation is that .span3 would just "work" like any other class that can be used as a mixin (though there, it was really desired to be more "extended").

The key benefit is in those instances where loops are generating numerical differences not only in class names themselves, but properties within those classes. Being able to dynamically generate a number of classes based on whatever formula one wants, and then also being able to use those as a mixin would seem worthy of the effort to implement the feature. I hope this basic idea and the use cases here are enough to warrant a deeper look into this idea.

[lukeapage]

I would be happy for it to work..

BUT

@a: "a";
.mixin() {
    @a: "b";
}
.mixin();
@{a} {
    prop: test;
    @b: test;
 }
 .b();
 .c {
    prop: @b;
 }

less is meant to work no matter the order of the statements.. e.g. you can use a variable that is defined later in the current scope.

that is why we do all the mixin calls before evaluating things that use variables.. but a selector uses variables.. so do the mixin calls twice and make sure we don't do the calls that have already been done? what if they change what the selector was?

The solution I have suggested (I think in the bugs you reference) is that people have to use extend for dynamic selectors.. that doesn't suffer from the above because extend happens after selectors have been calculated..

The next problem with the extend solution (and also calling dynamic mixins) is that we don't parse dynamic selectors.. so we have no idea ".class" is a class.. worst case scenario we would have to take something like this

@a: m;
@b: ~"-";
@c: ~".";
@d: class;
@{c}@{a}y@{b}@{d} {
}

render it to

.my-class

and then re-parse it into

{selector {element .class, combinator ""} }

BUT it would have to cope with selectors we don't recognise and also cope with someone who is purposefully trying to escape '&' because it is now some fancy css selector in 1 years time...

Ok, in the first instance we could just re-parse classes that are simple ^\.[a-Z-]+$ but that is (possibly) a path to inconsistency and pain

If you have any suggestions to work-around these problems (or perhaps a comment from @SomMeri as they are good at this kind of things) then please go ahead

[scottgit]

@lukeapage: Thank you for the detailed explanation of the difficulties involved. I am a creative thinker, but by no means a master at programming, so whether I would be able to come up with a creative solution to the issues you state or not I don't know; but I will certainly meditate on them further. I don't entirely know how LESS works, but your explanation has shed some light on that.

[SomMeri]

@LukePage Similar problem already exists in variable evaluation for mixins. Less solves it by making the order of the statements matter in special cases.

Similar problem description: Each mixin call both returns variables into local scope and reads variables from caller scope. Next example defines two such mixins. Each of them creates one variable and uses variable defined in the other one.

.mixin1() {
    @in1: "in mixin1";
    prop1: @in2; 
}
.mixin2() {
    @in2: "in mixin2";
    prop2: @in1;
}

I will call them from the same selector:

#selector {
    .mixin1();
    .mixin2();
}

What happens is that both @in1 and @in2 variables are returned into the selectors scope. However:

• .mixin1 does not see @in2 defined in .mixin2,
• .mixin2 does see @in1 defined in .mixin1.

So, the order of statements does matter in this case. Full sample case:

.mixin1() {
    @in1: "in mixin1";
    prop1: @in2; 
}
.mixin2() {
    @in2: "in mixin2";
    prop2: @in1;
}

.outer {
  @in1: "in outer";
  @in2: "in outer";
  #selector {
    .mixin1();
    .mixin2();
    selector-prop1: "in mixin1";
    selector-prop2: "in mixin2"; 
  } 
}

Generated css:

.outer #selector {
  prop1: "in outer"; // mixin1 ignores variable defined in mixin2
  prop2: "in mixin1";
  selector-prop1: "in mixin1"; 
  selector-prop2: "in mixin2"; // variable defined in mixin2 was returned
}

The selector-scope problem @LukePage describes could work the same way as variable evaluation for mixins. E.g. the selector would use the same variable value as its body see (assuming it does not redefine it). It would ignore returned from calls after its definition.

So this:

#outer { // enclosure around original case
  @a: "a"; 
  .mixin() {
    @a: ".b";
  }
  .mixin();
  @{a} { // this would compile int .b
    prop: test;
    @b: test;
   }
   .b();
   .c {
    prop: @b;
   }
}

Would be equivalent to this:

#outer {
  @a: "a";
  .mixin() {
    @a: ".b";
  }
  .mixin();
  .b() { //  @{a} was originally here
    prop: test;
    @b: test;
  }
  .b();
  .c {
   prop: @b;
  }
}

And both would compile into following:

#outer {
  prop: test;
}
#outer .c {
  prop: test;
}

[SomMeri]

Another interesting question -should the following work?

Sample input:

@variable: ~".one, .two";

@{variable} {
  declaration: value;
}

#caller {
  .one();
}

Similar case without variables work:

.one, .two {
  declaration: value;
}

#caller {
  .one();
}

[SomMeri]

One consequence of my previous suggestion is that following would fail:

.mixin() {
  @variable: .value;
  .value();
}

#space {
  .mixin();
  @{variable} {
    size: 2;
  }
}

while very similar construction would work (most likely):

#space {
  @variable: .value;
  .value();
  @{variable} {
    size: 2;
  }
}

Which is not good, I would expect those two to behave the same way. I will try to think about it more and collect various cases here. They may serve as test cases later on if we decide to do this.

[seven-phases-max]

Yes, unfortunately there're a few scope visibility problems that make "interpolated mixins" matching to fail in certain cases. However as @SomMeri already mentioned those issues are not unique to "intepolation" feature. Another example for collection:

@a: a;

#x {
    .@{a} {
        value: 1;
    }

    .a(); // Error

    & {
        .a(); // OK
    }
}

This one is very suprising (so simple and still fails?), but notice the following example with no interpolation:

.ns {
    .mixin() {
        value: 1;
    }
}

#y {
    .x {.ns};

    .x.mixin(); // Error

    & {
        .x.mixin(); // OK
    }
}

---

Update: I made further investigation of the example above (the "interpolated" one): interesting, it can be fixed by forcing the variable evaluation right at the "searching for match" point (magically it does not even break the "lazy loading" stuff). But it's hard to predict what other side-effects such forced evaluation may bring in... For example the following code will create a sort of "ghost" mixin:

@a: x;

div {
    .@{a} {
        value: @a;
        @a: y;
    }

    .x; // OK
    .y; // OK
}

result:

div {
  value: y;
}
div .y {
  value: y;
}

[donaldpipowitch]

+1
I would like to use interpolated selectors as a mixin. Example:

@prefix: test;

.@{prefix}-hello {
  color: red;
}

.world {
  .@{prefix}-hello;
}

[seven-phases-max]

Btw.,

.world {
  .@{prefix}-hello;
}

this is even yet another feature (something like this but with additional interpolation).