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.
Hi, @chriseppstein and @nex3. I know I started this conversation before really getting into the
@extend
implementation in libsass, but even after completing the implementation, I'd like to discuss the possibility of simplifying the behavior of@extend
. One of my team members described@extend
like this: the tool isn't dangerous because it's sharp, it's dangerous because it's unpredictable.A possibility that I've considered is adding an option to prevent
@extend
operating on anything other than placeholder selectors, enshrining that "conventional wisdom" as a compiler feature. Obviously, not everyone wants to extend only placeholders, so the option's default would retain the current@extend
behavior.A less sensible option is allowing a "naive_weave" function that eschews the philosophy of "the selector I'm extending from should work everywhere the selector I'm extending to does" in favor of string substitution. It's obviously not as powerful, but I think the power of
@extend
often works against CSS authors - not just because they don't understand@extend
but because even with a good understanding it's very hard to reason around. (My terrible illustration of the concept: DealerDotCom/sass@fd4048e)I don't disagree with the ideas and goals behind the current implementation and behavior of
@extend
. I think it's a really impressive solution to the defined problem. But I'd also like to imagine providing options that might give authors who prefer it an@extend
with a smaller scope - a sharper tool that's easier to predict.