swapping .clearfix and .clearfix() for css reduction

[Harris-Miller]

your current set up is so:

.clearfix() {
  &:before,
  &:after {
    content: " "; // 1
    display: table; // 2
  }
  &:after {
    clear: both;
  }
}

.clearfix {
  .clearfix();
}

consider switching to this:

.clearfix {
  &:before,
  &:after {
    content: " "; // 1
    display: table; // 2
  }
  &:after {
    clear: both;
  }
}

.clearfix() {
  &:extend(.clearfix all);
}

it will reduce the amount of resulting css when devs use your mixin in their own less files. There will still be some duplicate with .clearfix() calling both mixin .clearfix() and selector .clearfix (known issue with less.js, and I do wish you would change .clearfix() to .makeclearfix() or .addclearfix() or whatever to alleviate this problem, but I know you won't).

When the good fellas over at LESS do fix that problem, this code (combined with my suggested change)

.my-class {
  .clearfix();
}

will result in:

.clearfix:before,
.clearfix:after,
.my-class:before,
.my-class:after {
  content: " ";
  display: table;
}
.clearfix:after,
.my-class:after {
  clear: both;
}
.my-class {
  color: blue;
}

and of course if a dev uses .clearfix(); throught their own less files, the resultant compiled css will see a pretty significant reduction in size

[cvrebert]

Or you could just use

.my-class {
  &:extend(.clearfix all);
}

in your own Less file.

[Harris-Miller]

true. having the mixin still do that would be nice though

[mdo]

Yeah, we'll punt this to a v4 thing since our intention is that all mixins should never generate compiled styles on their own. In agreement with you on this though.