CODEWITHSUNDEEP
lessless-mixins
devwithenth
devwithenth

Reputation: 53

Mixin treat 2 equal class definitions differently

I start with a simple example:

.classA {
  color: red;
  .otherClass {
       color: yellow;
  }
}
.classB {
  .classA;
}

results in:

.classA {
  color: red;
}
.classA .otherClass {
  color: yellow;
}
.classB {
  color: red;
}
.classB .otherClass {
  color: yellow;
}

But:

.classA {
  color: red;
}
.class A .otherClass {
  color: yellow;
}
.classB {
  .classA;
}

results in:

.classA {
  color: red;
}
.class A .otherClass {
  color: yellow;
}
.classB {
  color: red;
}

I can't figure out why the compiler does not include the .otherClass in .classB. I mean both classA definitions are equal aren't they?

Is there a simple explanation for the weird behavior? Especially, is there a way to include .otherClass via mixins or do I have to copy the code?

Upvotes: 1

Views: 47

Answers (1)

seven-phases-max
seven-phases-max

Reputation: 11820

I mean both classA definitions are equal aren't they?

Nope, they indeed create equal CSS selectors/rulesets, but their Less definition is what exactly is different (in fact it's one Less ruleset definition in the first snippet, and two independent ruleset definitions in the second).

In other words: Mixins facility does not work with selectors in a HTML-like fashion (yep, this may be surprising at first). Mixins work with rulesets and their scope, thus the mixin expansion rule is as simple as:

.foo will match .foo ruleset(s) only (and expand all code defined inside that .foo only)

thus any separately defined .foo .bar etc. rulesets are never involved with .foo calls. (And yes, it never actually matters what CSS selectors either stuff results in the end. The only exception to this is namespaces, but that's another big story I don't want to confuse you with).

For your particular example I'd say that extend will fit better.

Upvotes: 1

Related Questions