In short: no, currently this is not possible (a variable always goes as one mixin argument). (The "list to arguments expansion" feature is actually implemented and may appear in Less 2.0 but it needs some upvotes, see #1857 - do not hesistate to +1 there).
Workarounds:
1
You can create 'smart arguments handling' via mixin specializations (see Pattern Matching).
E.g. (Less 1.6+):
.border-radius(@tr: 0, @br: 0, @bl: 0, @tl: 0) when (default()) {
border-top-right-radius: @tr;
border-bottom-right-radius: @br;
border-bottom-left-radius: @bl;
border-top-left-radius: @tl;
}
.border-radius(@values) when (length(@values) = 4) {
.border-radius(
extract(@values, 1),
extract(@values, 2),
extract(@values, 3),
extract(@values, 4));
}
// you also have to provide specializations for
// (length(@values) = 2) and (length(@values) = 3)
// cases if you need to handle them
// ...............................................
// usage:
@myRadius: 3px, 0, 0, 3px;
a {
.border-radius(1px, 2px);
}
b {
.border-radius(@myRadius);
}
2
Same as above, just a bit less verbose variant (Less 1.5+):
.border-radius(@values...) {
.-() {@tr: 0; @br: 0; @bl: 0; @tl: 0} .-();
.-() when (length(@values) > 0) {@tr: extract(@values, 1)}
.-() when (length(@values) > 1) {@br: extract(@values, 2)}
.-() when (length(@values) > 2) {@bl: extract(@values, 3)}
.-() when (length(@values) > 3) {@tl: extract(@values, 4)}
border-top-right-radius: @tr;
border-bottom-right-radius: @br;
border-bottom-left-radius: @bl;
border-top-left-radius: @tl;
}
// ...............................................
// usage:
@myRadius: 3px, 0, 0, 3px;
a {.border-radius(1)}
b {.border-radius(1, 2)}
c {.border-radius(1, 2, 3)}
d {.border-radius(1, 2, 3, 4)}
e {.border-radius(1 2 3 4)}
f {.border-radius(@myRadius)}
// etc.
3
Not a workaround but "just in case" remark, if the use case is limited to basic CSS properties it's actually questionable if you really need default values to be 0 instead of actual CSS "default value" (i.e. why would we need .border-radius(1, 2) to be expanded to border-radius: 1 2 0 0; and not to border-radius: 1 2;?). Contrary I would expect the mixing to follow CSS syntax and that way it can be as simple as:
.border-radius(@values...) {
// ...
border-radius: @values;
}
// ...............................................
// usage:
@myRadius: 3px 0 0 3px; // no commas here
a {.border-radius(1)}
b {.border-radius(1, 2)}
c {.border-radius(1, 2, 3)}
d {.border-radius(1, 2, 3, 4)}
e {.border-radius(1 2 3 4)}
f {.border-radius(@myRadius)}
P.S. And as my always: if your use cases for this kind of stuff are limited to vendor prefixes, consider to add an autoprefixing tool into your build chain to stop wasting your time for writing these vendorizing preprocessor mixins (see also).
