TL;DR Variables in LESS get overwritten, but mixins get combined. To overwrite a mixin, you’ll have to use CSS techniques or guard expressions.
LESS is a dynamic stylesheet language which adds a lot of features to CSS that are common to most programming languages. There’s a lot LESS can do, including adding variables, mixins, and math. Yes, math. You then compile your LESS files into the CSS that our browsers know and love. Whether you hate CSS or love it (like I do), LESS is awesome.
I’ve only started using LESS, and I was curious how it handles variables and mixins that have the same name. In a lot of programming languages, re-declaring a variable or function has the effect of overwriting the original. In CSS, the rules are cascaded, newer ones having precedence over older ones, depending on specificity. How does it work in LESS?
Variables get overwritten. If you first write @value: #000; and later write @value: #999; the value of @value when your CSS is compiled will be #999. This is true for @value everywhere, including previously included files. (Of course, follows the rules of scoping in LESS apply.)
Mixins, including parametric mixins with the same signature, get combined. Literally identical declarations will not be duplicated, but all other rules, even for the same property, just get concatenated together in one large block. Rules are listed in the order that the mixins are declared. The exception is identical rules, which are placed at their last declaration.
This behavior is probably deliberate, since it falls in line with CSS’s cascading nature. It appears that if you want to overwrite a mixin, you either have to redefine those properties the same way you would in pure CSS, or you can write a series of parametric mixins with guard expressions to ensure you get the mixin you want.
Here’s some code to illustrate the behavior I saw. There’s an included_file.less and styles.less which get compiled into the styles.css.