mixin with IE filter repeating old parameter values

[wkeese]

Starting in 1.1.5, IE filters clauses work without the %(..., val1, val2) or ~"..." workarounds. Thanks for implementing that (assuming the support was intentional, rather than just a fluke.) There's a bug with variable substitution though, with repeated calls to the same mixin:

.vertical-gradient(@color) {
    background-color: @color; // the base color
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=@color, endColorstr=@color);
}

.rule1 {
    .vertical-gradient(#fff);
}

.rule2 {
    .vertical-gradient(#000);
}

The generated CSS for .rule2 is:

.rule2 {
  background-color: #000000;
  filter: progid:dximagetransform.microsoft.gradient(startColorstr=#ffffff, endColorstr=#ffffff);
}

Note that background-color gets the correct parameter value of #00000, but the filter clause gets the #ffffff parameter value from the previous call to the mixin.

BTW, you should update the website to explain the %() printf type method, and the e() method, and change the example of the ~"...", since it implies that it's needed for filters which is no longer the case.

[cuzzins]

I am seeing the same issue, was updating part of elements.less to include some IE specific filters for gradients:

.gradient(@color: #F5F5F5, @start: #EEE, @stop: #FFF) {
    test: @start @stop;
    background: @color;
    background: -webkit-gradient(linear, left bottom, left top, color-stop(0, @start), color-stop(1, @stop));
    background: -moz-linear-gradient(center bottom, @start 0%, @stop 100%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='@{stop}', endColorstr='@{start}',GradientType=0 );                  
}

The code generated (am using less.app) looks like this in the first call to the mixin:

nav a {
    ...
    background: #b20000;
    background: -webkit-gradient(linear, left bottom, left top, color-stop(0, #7f0000), color-stop(1, #b20000));
    background: -ms-linear-gradient(bottom, #7f0000, #b20000);
    background: -moz-linear-gradient(center bottom, #7f0000 0%, #b20000 100%);
    filter: progid:dximagetransform.microsoft.gradient(startColorstr='#b20000', endColorstr='#7f0000', GradientType=0);
    ...
}

And on the second:

nav a span {
    ...
    background: #e50000;
    background: -webkit-gradient(linear, left bottom, left top, color-stop(0, #990000), color-stop(1, #e50000));
    background: -ms-linear-gradient(bottom, #990000, #e50000);
    background: -moz-linear-gradient(center bottom, #990000 0%, #e50000 100%);
    filter: progid:dximagetransform.microsoft.gradient(startColorstr='#b20000', endColorstr='#7f0000', GradientType=0);
    ...
}

Note how the two filter lines are the same, even though different colors were passed. Just figured another sample case might be useful.

[cuzzins]

As an aside, the issue does go away if the filter is escaped - sorry, missed the documentation regarding escaping, but still seems like there is an issue:

filter: ~"progid:DXImageTransform.Microsoft.gradient( startColorstr='@{stop}', endColorstr='@{start}',GradientType=0 )";

[wkeese]

Right. Get the new version of less. I filed a ticket about this
problem already: #534

On Sat, Jan 7, 2012 at 12:57 AM, cuzzins
reply@reply.github.com
wrote:

As an aside, the issue does go away if the filter is escaped - sorry, missed the documentation regarding escaping, but still seems like there is an issue:

   filter: ~"progid:DXImageTransform.Microsoft.gradient( startColorstr='@{stop}', endColorstr='@{start}',GradientType=0 )";

---

Reply to this email directly or view it on GitHub:
#534 (comment)

[lukeapage]

This happens when a node does not clone itself properly when eval'd - if it alters itself then the next time the mixin is called it will not be correct.