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 would argue that the user's intention when writing
@extend
is that it follows the semantics listed above, not that it perform some specific mechanical replacement. Users shouldn't have to think about what the underlying implementation of these semantics are. The behavior you're suggesting is mechanically-oriented rather than being focused on how the actual elements get styled, which is bad.