Extending a compound selector violates extend semantics

[nex3]

Currently, when a compound selector is extended, Sass will only replace instances of the full extendee with the extender. For example:

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a.b}

produces

.a {x: y}
.b {x: y}
.a.b, .c {x: y}

when it should produce

.a, .c {x: y}
.b, .c {x: y}
.a.b, .c {x: y}

according to the semantics of @extend. We should fix this, especially as CSS moves closer to supporting @extend natively.

Tasks:

• Deprecate existing behavior in stable.
• Remove behavior from master.

[lifeiscontent]

@nex3 any ideas when this might be fixed?

[chriseppstein]

To clarify:

.c { @extend .a.b } means "Style elements with class c, as if they had both of the classes .a and .b", It's semantically identical to .c { @extend .a; @extend .b; }

[ArmorDarks]

To be honest, I'm slightly confused.

This example seems to be perfectly right result for .c {@extend .a.b}:

.a {x: y}
.b {x: y}
.a.b, .c {x: y}

It's because we clearly asked to extend .a with specified by .b selector, not just .a or .b, or .a.b.

If we'd like to receive this:

.a, .c {x: y}
.b, .c {x: y}
.a.b, .c {x: y}

I'd more expect syntax like

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a, .b, .a.b}

or

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a.; @extend .b; @extend .a.b}

[nex3]

@ArmorDarks When you write A {@extend B}, that means "all elements that match A should be styled as though they also matched B". In the example above, that translates to "all elements that match .c should be styled as though they also matched .a.b". If an element matches .a.b, that means it also matches both .a and .b individually, so .c {@extend .a.b} should mean the same thing as .c {@extend .a; @extend .b}.

[ArmorDarks]

If an element matches .a.b, that means it also matches both .a and .b individually, so .c {@extend .a.b} should mean the same thing as .c {@extend .a; @extend .b}.

I still miss the logic why .a.b. also matches .a and .b individually. Those are 3 different selectors, it just so happens that they consist from same elements, but nothing more.

It just goes against CSS logic, since when in CSS we write more complex selectors, we increasing its specificity on purpose, to ensure that only "those instances of class" with class='a b' will receive that style, not class='a' and class='b'.

I think Sass can follow pretty much close same logic — when you increase specificity of extend, you want to extend only specific selectors, not everything related to them, otherwise you would write more generic extend.

[meowsus]

@ArmorDarks that's the behavior I would expect. @extend should extend the selector that is passed to it. Anything more would risk yielding unexpected results, not to mention further tarnish it's already eroded reputation.

[mdesantis]

-1 to this. If I want .c to extend .a and .b I write .c { @extend .a; @extend .b; }.

[jdurand]

I'm receiving deprecation warnings linking to this issue for several bits of SCSS that look like this:

.icon-check:before { content: "\f13e"; }

.foo {
  // [...]
  &:after {
    // [...]
    @extend .icon-check:before;
  }
}

This SCSS should probably be rewritten, but that's not the point; I don't think it's semantically wrong.
Why is it triggering this warning?

[combs]

Sorry. I meant to point out that the deprecation warning cites a dead URL: See http://bit.ly/ExtendCompound for details.

[nex3]

Thank you for the report. It looks like the JavaScript we set up to redirect anchors in the new documentation isn't working. I'll look into it.

[esr360]

@nex3 please look at this simplified example that uses a compound selector and suggest the correct way I should be doing it:

https://codepen.io/esr360/pen/zQRZdY

The same code on SassMesiter throws an error, and the "suggestion" from the error throws another error...not a particularly good developer experience.

[nex3]

@esr360 I would change @extend [class*="button-"][class*="-round"] to @extend [class*="button-"], [class*="-round"], which produces the same output and accurately represents the idea that .myButton is a button and is round. This works exactly the same as if you had written <div class="button-round myButton"> in your HTML instead of writing the @extend.

It's also worth noting that the comments on your styles are contradictory. You say that all buttons should be styled with the .button styles, but then you say that .myButton should only extend the round button styles. Is it a button or isn't it? This kind of semantic confusion is exactly the problem with extending compound selectors.

[esr360]

@nex3 I really appreciate your response.

Actually you can see that whilst in this particular case the net effect is the same, the CSS output is in fact different:

.button, [class*="button-"], .myButton {
  display: block;
  background: red;
}

[class*="button-"][class*="-round"], .myButton {
  border-radius: 4px;
}

.myButton {
  display: inline;
  background: blue;
}

...vs the original:

.button, [class*="button-"] {
  display: block;
  background: red;
}

[class*="button-"][class*="-round"], .myButton {
  border-radius: 4px;
}

.myButton {
  display: inline;
  background: blue;
}

The difference being that myButton in the original case does not extend the .button styles. The display property in the updated suggestion (https://www.sassmeister.com/gist/2dbeb5ed3178a47d3de0319050776167) will now be overwritten. If .button were to contain any properties that .myButton did not, .myButton would incorrectly extend these properties as well, but in reality we just want to extend the border-radius property.

I take your point on board about semantics, the example I provided doesn't do a good job at showing the problem in a practical sense, only a logical one, so please consider the same question to this revised example:

https://codepen.io/esr360/pen/zQRZdY

Can you suggest a correct way to achieve the above?

[binki]

@esr360 Using the placeholder selector technique I described in an earlier comment, you can get identical output. I have forked your codepen here: https://codepen.io/apostrophe/pen/gJKBbm .

I tried to determine if this pattern would be compatible with your code base. You appear to be using pattern matching to incrementally accumulate rules onto an element. However, in defining [class^="button-"][class*="-primary"] , your use of @extend created a new rule set in a way that didn’t participate in that pattern-matching-based rule accumulation. Thus, I don’t think the use of placeholders is a step backward for the example you provided.

[esr360]

You appear to be using pattern matching to incrementally accumulate rules onto an element.

@binki thanks for much for actually understanding what it is I'm trying to do - this is exactly right.

Your solution using placeholders seems like it could work, though it will require my framework to be re-written, and will still feel like a "hack" to get around this change, which I'm still struggling to see the logic of.

[nex3]

I take your point on board about semantics, the example I provided doesn't do a good job at showing the problem in a practical sense, only a logical one, so please consider the same question to this revised example:

https://codepen.io/esr360/pen/zQRZdY

Can you suggest a correct way to achieve the above?

This one's actually easier: just get rid of [class*="button-"] in your extends. Because the extending selector already includes [class*="button-"], Sass's intelligent unification will avoid duplicating that selector. See my forked pen to see it in action.

[esr360]

@nex3 that's very interesting! At first glance, it seemed like the code would break if I introduced some other style that had [class*="-round"] (e.g. [class*="icon-"][class*="-round"]), since all [class*="-round"] cases would be extended, and whilst it generated the following CSS:

[class*="icon-"][class*="-round"], 
[class*="icon-"][class*="button-"][class*="-primary"] {
  border-radius: 50%;
}

it shouldn't break anything. Ideally it wouldn't be in my output because I'm really just wanting to extend [class*="-round"] for buttons only. In my framework, any component that has round modifiers will extend button into the selector, but it won't break anything I don't think so I suppose this is acceptable.

Thanks very much for putting time in to help me.

[nex3]

In theory, you could have an element with class="icon-button-primary" that should have that border-radius. You could rewrite your selectors to be [class^="icon-"] and [class^="button-"], in which case we could potentially detect that they're mutually incompatible during intelligent unification (currently we don't have that logic but it wouldn't be too hard to add).

[denholmscrimshaw-se]

@nex3 Hi, I was wondering if you could clarify something for me, as I'm trying to resolve these deprecation warnings.

You can use compound selectors to define new rules that are present in neither of the composing selectors individually, like in this CodePen where .popover is combined with .top https://codepen.io/denholms/pen/MWYavzm.

You say "If an element matches .a.b, that means it also matches both .a and .b individually", but aren't you describing ".a .b", not ".a.b" where the classes are used simultaneously?

[lwxbr]

Please, @nex3, just create a flag ignoring @extend strict rules and let us compile grouped selectors. For example:

$ sass --ignore-extend-rules <args>

Okay, If that breaks the rules of 'extend' and it can be unbearable to do, lets create another keyword to fit the a.b cases.

[nex3]

@dscrimshaw

@nex3 Hi, I was wondering if you could clarify something for me, as I'm trying to resolve these deprecation warnings.

You can use compound selectors to define new rules that are present in neither of the composing selectors individually, like in this CodePen where .popover is combined with .top https://codepen.io/denholms/pen/MWYavzm.

You say "If an element matches .a.b, that means it also matches both .a and .b individually", but aren't you describing ".a .b", not ".a.b" where the classes are used simultaneously?

If an element matches .a .b, that means the element matches .b and it has a parent that matches .a. If an element matches .a.b, that means it matches both .a and .b individually. For example, in this CodePen:

• The p element matches .border.color (you can tell because it has a red background).
• The p element matches .border (you can tell because it has a black border).
• The p element matches .color (you can tell because the text is blue).

@lwxbr We don't add flags that affect compilation behavior for many reasons. It adds complexity for every user, it increases our maintenance overhead, and worst of all it means that Sass stylesheets compile to meaningfully different CSS in different contexts.

Also, we don't consider the ability to extend compound selectors to be desirable behavior for anyone. I understand why people are using it as a convenient shorthand for manually writing out the selectors they need, but that shorthand almost universally produces more confusion for future readers of those stylesheets than it saves in the short term. It's not something we want to encourage.

[denholmscrimshaw-se]

@nex3 Thanks for the clarification.

If you had the intent to extend the rules of .border.color though, for instance (and sorry if this is a poor example - it's the end of my working day) if you're using border as a styling class and color as representing a state, and you're extending these rules on a main page to something that's now in a modal window or something, as far as I understand you now can't? Seems like you have to define a new class for that styling+state scenario to then extend?

[nex3]

Can you give a more concrete example?

[lwxbr]

Also, we don't consider the ability to extend compound selectors to be desirable behavior for anyone.

@nex3, this issue is definetely a wontfix issue, I suggest you tag it as it really is.

I think the fair solution for this case is let the users solve this by themselves. For example: I don't will implement that feature in the core of the sass, but you can write a plugin if you want and distribute it to others if that might help them instead of fork sass and make another sass compilers, etc, etc.

But saying like "that is it and period" will keep this issue and others in this state of unsolvable problems.

[maxjf1]

Currently, when a compound selector is extended, Sass will only replace instances of the full extendee with the extender. For example:

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a.b}

produces

.a {x: y}
.b {x: y}
.a.b, .c {x: y}

when it should produce

.a, .c {x: y}
.b, .c {x: y}
.a.b, .c {x: y}

This is one of the reasons i stopped using sass. This feature was the best one of the tool. And just because someone didn't like the way it was implemented, it was removed to everyone (and nowdays is almost impossible to use it). I used a lot this feature @extend .a.b to integrate with old layouts and extend styles. Today, if you didn't apply an strict pattern such as BEM, you are scrolled.

You coud just achive it in this example by just using:

.a {x: y}
.b {x: y}
.a.b {x: y}

.c {@extend .a, .b}

but,

NO

everyone need to loose this feature.

How do i supose to fix this case:

// base
.foo {
    .bar {
        .button {
            background: red;
            color: white;
        }
    }
}

// extending
.my-link {
    @extend .foo .button;
    border: 1px solid yellow;
}

whithout changing the base code? it's impossible. Thank you 👌

[maxjf1]

but that shorthand almost universally produces more confusion for future readers of those stylesheets than it saves in the short term. It's not something we want to encourage.

@nex3 you are not encouraging, you are literally FORBIDDING anyone to use this feature. As a developer, i like to make choices about my project and decide myself if something is or isn't suitable or right to do, and not let someone else decide for me. If it was really an recommendation, it would only generate an warning, not an error.

This is a useful feature and not just an good practice. There is a lot of projects that may take advantage of this, like

• Extending another project / theme style
• Supporting an legacy project style
• Extend/modify behaviors when you are not allowed to change the base code (using an elements library such bootstrap for instance)
• Extend/modify generated CSS/SCSS without changing the source code (eg an generated css code from webflow that may be generated again)

If still isn't "right" to use it in @extend, just please create a way to do so. As @lwxbr , an flag or even an plugin to sass. Or, create another tag such as @inject or somehting like it.

This behavior is only usefull when you start an scss project from scratch, and using an strict pattern like BEM. But when you extend another layout, or start from an base such as bootstrap, this is only an bad limitation

[connorlufei]

Replacing @extend a.b with @extend a, b might be semantically identical but it produce a bloated output in my case. I have a sass library that customizes bootstrap.

For example, I have a rule that is like

.navbar-nav .active .nav-link {
   @extend .nav-link.active; 
}

Which is meant to make selector .navbar-nav .active .nav-link extend the styles from selector .nav-link.active(very few lines of styles). output css has around 19k lines.

But if I use @extend .nav-link, .active; or @extend .active; , the output has 250k lines of css. Since .active and its combination selectors has a lot of styles, output contains a lot of styles rules that is not expected to exist.