parametric mixin issue

[stevenvachon]

.transition (@transition)
{
    -moz-transition: @transition;
    -webkit-transition: @transition;
    transition: @transition;
}

#something
{
    .transition(color 1s);  /* works */
    .transition(color 1s, font-size 1s);    /* breaks */
}

[SomMeri]

The compiler interprets colon in your mixin call as arguments separator. If you put semicolon after the argument, then it will treat the colon as a list separator.

Fixed example:

.transition (@transition)
{
    -moz-transition: @transition;
    -webkit-transition: @transition;
    transition: @transition;
}

#something
{
    .transition(color 1s, font-size 1s;);    /* added semicolon here*/
}

You can find more details at less4j wiki or at lesscss.org - search for Mixins With Multiple Parameters.

[stevenvachon]

Thank you. Isn't there a way to fix this so that "weird" code is not required?

[seven-phases-max]

Well, you could try to invent something better :) See #35.

[stevenvachon]

:) so, it's only temporary until support for , delimiters is removed?

[seven-phases-max]

No, not really. The , support will never be removed. Try to guess why.

[stevenvachon]

Because everybody reads the docs? ;-)

[seven-phases-max]

No, just because of zillion less files out there that gets immidiately broken.
(As for the It is recommended to use semicolon docs statement, well, it's quite subjective thing... For example I personally would recommend exactly the opposite because of readability).

[stevenvachon]

Yes, as a result of not reading the docs.. and old code.

[SomMeri]

@seven-phases-max readability is matter of habit :).

[seven-phases-max]

@SomMeri And the habit is a matter of previous experience. Since LESS is not usually the first language one learns it is safe to assume that a fuction/mixin call statement with arguments separated by semicolons is harder to read for him. If I used to read/write some code before, my brain is already tuned to percieve certain character/symbol patterns/sequences as a whole chunks that correspond to specific language statements (and each sequence that does not fit any pattern makes me to stop "scanning" and parse the code on a word-by-word/symbol-by-symbol basis instead).
Now by counting the number of languages out there with the semicolon as function argument separator it is even possible to estimate how many people have (or will like to have) the habit of such syntax :).

In summary I'd say that "the comma there" is too fundamental habit for many, and they need something really weighty reason to shift. And

Using comma as mixin separator makes it impossible to create comma separated lists as an argument.

is just not enough (even if value lists are significant feature of the language itself).

Of course I oversimply things a bit (not counting "designers vs. developers" stuff, "mixins vs. functions" etc.) but in general I think that when the docs (and some libraries like BS) started to push ; style this begun to work against LESS, making its learning curve more steep. Though I have no intentions to propose to change this or something like that. Just an observation.

[SomMeri]

@seven-phases-max What do you mean by BS?

We can change the "It is recommended to use semicolon" sentence into something like "Although comma is more traditional and look familial to new users, semicolon has its advantages too". Not ideal way to write it, but you can get the idea.

[seven-phases-max]

@SomMeri
BS - Bootstrap.

As for changing the docs, I don't know, I think I may be too biased (because of my programming backgrounds) to express any particular opinion on what could possibly serve better.

[stevenvachon]

my brain is already tuned to percieve certain character/symbol patterns/sequences as a whole chunks that correspond to specific language statements

As designers and programmers, we simply check the docs for syntax examples and we're ready to move forward. We don't mind following the rules as long as they're straightforward. It's like learning PHP, we don't have a problem using $ in front of variables. When something doesn't work, the compiler tells us why and we refer to docs again if necessary.

If ; were forced instead of allowing , for separating arguments, the problem of .�transition-mixin(color 2s,font-size 2s;); would not exist and no further—and less obvious—documentation would be required.

You guys could always go the "v2.0" route for making such drastic changes allowing all the libraries to catch up.

[seven-phases-max]

my brain is already tuned to percieve certain character/symbol patterns/sequences as a whole chunks that correspond to specific language statements

That quote is about readabilty, or more specifically about "how many efforts you devote to some piece of code to understand what it's about and how fast you can do this".

I have no problem using both .transition-mixin(@a, @b;); and .transition-mixin(@a; @b), they both break my "perception patterns" but I'll prefer to use the first syntax in my code just because it does not happen too often.
(Btw. don't forget about .transition-mixin(@a: @b); somewhere in between :)

[stevenvachon]

.transition-mixin(@a: @b); looks like a declaration, whereas ; at least communicates a termination.

[SomMeri]

@stevenvachon In a way, it is really declaration. You can "declare" arguments in your mixin call. That allows you to skip any arguments you want to skip - it is useful in combination with default values.

[SomMeri]

@seven-phases-max There are plans for backward incompatible less 2.0, the most important is this one. I do not remember the rest nor where they are listed.

[seven-phases-max]

@SomMeri Thanks. Yes, I'm aware that --strict-math: on is declared to become default eventually
(I actually turned it on in all of my build scripts a while ago so any code coming from me has strict parenthesis for math ops). Though I wonder if this change is planned only for v2.0 or may come earlier (counting the fact that it was on by default in 1.4 betas).

Btw., for that matter, I guess that if the support for , argument delimiters is planned to be removed the docs should mention this explicitly and recommend to upgrade the code as well.

---

Either way it seems like we've gone too far in this discussion, and since it was somewhat triggered by my answer to:

so, it's only temporary until support for , delimiters is removed?

Let me to re-answer it: "Yes, maybe" (if you're fine with temporary defined as an unknown period like {put your estimation for v2.0 here} :).