The ordering of a var declaration and a mixin call will change the css output.

[bthule]

In other issues (e.g. #297), it has been said that less variables act like constants just as in CSS, however, less has scoping constructs whereas CSS does not. So, from a single global scope, that idea works-- but when we start considering local scopes, it causes confusion because it is unclear whether the local scopes should leak to the outer/global scope.

Consider the following examples where we see that less.js is not consistent in its handling of variables in different scopes:

#namespace {
    .mixin() {
        @test: #FFF;
        .shouldHaveFs {
           color: @test;
        }    
    }
}

.shouldHaveZeros {
    color: @test;
}

// the ordering of these next two lines changes the output!
@test: #000;
#namespace > .mixin();

This outputs a result that acts like localized scopes:

.shouldHaveZeros{color:#000000;}
.shouldHaveFs{color:#ffffff;}

But if you change the order of the last two lines, then the result acts like it has only a global scope:

.shouldHaveFs{color:#ffffff;}
.shouldHaveZeros{color:#ffffff;} 

In the discussion of #297, it was said by a few that css variables should ONLY be considered to be like css constants. If this is to be true, then the variables should always work as global constants just like CSS. That means that less.js should always leak local variables to the global space.

That would severely limit the usefulness of less in a lot of projects which aim to have a single CSS file, but what to safely include less files from third party projects.

I prefer the localized scopes version, and think less should expand its view and say that less variables are like CSS "constants" but only within their local scope-- and local variables should never leak to their parent or global scope.

[SomMeri]

I think that it is the same as #1120 The other issue has some explanations in it and workaround too.

[lukeapage]

closing as duplicate of #1120