When you write
.a .b .c .d {
color: blue;
}
What you're saying is
Any element with class
d
that's nested beneath elements with classesa
,b
, andc
in that order should have blue text.
Then when you write
.e .f .g .h {
@extend .d;
}
what you're saying is
Any element with class
h
that's nested beneath elements with classese
,f
, andg
in that order should be styled as though it also has classd
.
The conjunction of these two statements implies
And element with class
h
that's nested beneath elements with classese
,f
, andg
in that order and beneath elements with classesa
,b
, andc
in that order should have blue text.
It's important to note that the two nesting requirements here don't have any particular order. Both of the following spans should have blue text:
<div class="a">
<div class="b">
<div class="c">
<div class="e">
<div class="f">
<div class="g">
<span class="h">Order 1</span>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="e">
<div class="f">
<div class="g">
<div class="a">
<div class="b">
<div class="c">
<span class="h">Order 1</span>
</div>
</div>
</div>
</div>
</div>
</div>
The way to represent this in CSS is
.a .b .c .d, .a .b .c .e .f .g .h, .e .f .g .a .b .c .h {
x: y; }
Note that fully satisfying those semantics would produce exponential output, so Sass elides all but the two most likely permutations for space reasons.
I agree that users shouldn't have to think about it - but in practice the mechanics of Sass have caused a lot of users to find themselves surprised by the need to think about it pretty hard, because the CSS that's been generated to protect them has caused more problems than it's solved. That said, the solution to that problem already exists: to not use Sass's features. (You've probably already read a number of articles like this: http://csswizardry.com/2014/01/extending-silent-classes-in-sass/)
But I see that we have a difference of philosophy about what Sass should (ideally) provide. As a stylesheet author, I'm ok with using a small subset of Sass's features to achieve the right balance of power in authoring and performance in the browser. As a contributor to libsass, it'll be harder for me to put resources behind the non-naive implementation of extend, though I agree in principle that Sass implementations should be consistent.
Thanks for filling me in on the reasons Sass does what it does where extend is concerned!