I like the idea of combining contexts/queries per extend, but not necessarily combining contexts/queries between different extends or with non-extended rulesets. My ideal would be:

SCSS

%half {
 width: 50%;
}

%full {
 width: 100%;
}

.one {
  @extend %half;
}

.two {
  @extend %full;
  @media (min-width: 30em) {
    @extend %half;
    color: blue;
  }
}

.three {
  @media (min-width: 30em) {
    @extend %full;
  }
}

CSS

.one {
  width: 50%;
}

@media (min-width: 30em) {
  .two {
    width: 50%;
  }
}

.two {
  width: 100%;
}

@media (min-width: 30em) {
  .three {
    width: 100%;
  }
}

.two {
  color: blue;
}

...keeping source order and general extend behavior as expected. For me, simplicity of behavior and sticking close to existing patterns trumps optimization. I'd prefer to combine all mqs with a post processor or optional Sass flag in a separate step.

I'm not sure what the status of this behavior (which has been proposed a couple times) is; if anyone knows of an issue tracking/rejecting it, please let me know. Really, anything that gets @extends and MQs working together is good for me.

@robwierzbowski If we add this flag, it will likely have the behavior you suggest. Changing the source order is something we're very keen to avoid.

The issue here is that you have a pattern that is not properly abstracted. The pattern is that there is some elements which are full width for small screens that become half width for large screens. If you have expressly created this abstraction you will have an easier to understand stylesheet and Sass won't have to do backflips to optimize your unnamed abstractions.

@mixin column($width, $last: $width == 100%) {
  float: left;
  width: $width;
  @if $last {
    clear: both;
  }
}

@mixin for-large-screens {
  @media (min-width: 500px) {
    @content;
  }
}

%full {
  @include column(100%);
}

%half {
  @include column(50%);
}

@include for-large-screens {
  %half-lg {
    @include column(50%);
  }
}

%full-to-half {
  @extend %full;
  @extend %half-lg;
}

.sidebar-1 {
  @extend %full-to-half;
  background: blue;
  @include for-large-screens {
    background: red;
  }
}

.sidebar-2 {
  @extend %full-to-half;
  background: green;
  @include for-large-screens {
    background: orange;
  }
}

.content {
  @extend %half;
  background: purple;
}

.sidebar-1, .sidebar-2 {
  float: left;
  width: 100%;
  clear: both;
}

.content {
  float: left;
  width: 50%;
}

@media (min-width: 500px) {
  .sidebar-1, .sidebar-2 {
    float: left;
    width: 50%;
  }
}
.sidebar-1 {
  background: blue;
}
@media (min-width: 500px) {
  .sidebar-1 {
    background: red;
  }
}

.sidebar-2 {
  background: green;
}
@media (min-width: 500px) {
  .sidebar-2 {
    background: orange;
  }
}

.content {
  background: purple;
}

I remain unconvinced that Sass needs any magic for extend within runtime-based contexts. I find the above stylesheet more understandable than your original. Additionally, by reading it, it's very easy to deduce what the output will be.

@chriseppstein The issue with what you've written is it actually goes against the best practices of responsive web design. When working with media queries, the best practice is to make changes as needed and not necessarily group them all together, especially true when it comes to grids as different layouts tend to ebb and flow much more than full-to-half. With the way you've described, every single different permutation of change between every single set of grids one may have across all permutations of media queries would need to be made available which is a maintenance nightmare and will easily become hard to decipher for developers. On the other hand, if each layout were to have their own extendable and could be called as such, that would make it infinitely easier to mix and match, and what was happening would be easier to grok.

Let's also not forget that this isn't just for layouts, it's for any number of items. Background image, clearfixes, box sizing, fonts stacks and definitions, all can benefit from being able to be extended from within a MQ and have a context created and needing to create extendable classes for all of their potential permutations seems like a maintenance headache as well.

+1, I'm completely agree with the latest comment of @Snugug.
I already had this need, and had to do some code gymnastics to get round this limitation. This gave things ​​less flexible, and more difficult to read and maintain.

My example was based off @Snugug's (which I think is valid). But disagreeing with the example is not a disagreement with the issue.

@chriseppstein Do you think we shouldn't be able to extend a(ny) value from within a media query? By which I mean apply <rules> to <selector>, where <selector> is .class or @media (foo) { .class }.

In my experience this is one of the most often requested features in Sass, both verbally among my peers and from what I see in issue queues and comment threads on the internet.

I want to continue considering this. Even if it's the case that there's a better factoring available for every stylesheet that wants to extend out of a media query, it's clear that users aren't able to see that refactoring easily. @robwierzbowski is right that this is highly-requested functionality. People run into the issue of extending out of media queries frequently, and I'd like a solution that we can at least explain in the error message.

The definition of A { @extend B; } is to style elements matching A as if it matched selector B.

The definition of @media (some runtime expression) { A { @extend B; } } is to style elements matching A as if matching B when the media matches some runtime expression.

I'm not trying to tell people that they are wrong for wanting this to work. I think they are right for wanting this to work. Hell, I want this to work. But the bottom line is that a precompiler simply cannot implement this semantic without yielding output that we've deemed as too magical and bloat prone.

I'm love that you guys want this feature. You're preaching to the choir. You need to take this argument up with the CSS working group. Until then, I feel the @at-root directive provides enough of an escape hatch for people who know what they are doing to accomplish their needs.

I don't see any point in continuing to beat this dead horse.

I think it's reasonable to allow users to opt in to the extra bloat. As I mentioned above, it's clear that users aren't able to easily figure out how to use @at-root to work around this.

@nex3 I'm not convinced. We've only just introduced @at-root and there is a learning/education period that is required to decide that. Furthermore, we have a way to produce bloat: mixins. I am against making @extend sometimes a selector operation and sometimes a rule copy operation. I'd rather see users write mixins that conditionally extend or include. This is not a feature Sass needs to add.

Additionally, I feel this will only increase the confusion about how people think that placeholder selectors can only be used like simple mixin declarations (having no arguments) rather than the powerful selector concept that they are.

We've only just introduced @at-root and there is a learning/education period that is required to decide that.

Can you summarize tersely how to take any cross-media @extend and make it work using @at-root? I don't fully understand the process myself.

Furthermore, we have a way to produce bloat: mixins. I am against making @extend sometimes a selector operation and sometimes a rule copy operation.

I would rather have users think of @extend as a semantic operation than in terms of its effect on the physical stylesheet. Making users switch between @extend and @include based on whether they're within a @media block makes the semantic abstraction more leaky, while having Sass make @extend itself work however necessary makes it less leaky.

Additionally, I feel this will only increase the confusion about how people think that placeholder selectors can only be used like simple mixin declarations (having no arguments) rather than the powerful selector concept that they are.

I'd rather focus our education efforts here than on complex work-arounds for @extend in @media.

Can you summarize tersely how to take any cross-media @extend and make it work using @at-root? I don't fully understand the process myself.

@at-root (without: media) { & { extend .something; }} removes the runtime context so that the extend operation can be performed as if it were not within a media context. This is useful in places where the base definition is a constant across all media definitions or is appropriately overridden via the cascade even when applied across media types.

I would rather have users think of @extend as a semantic operation than in terms of its effect on the physical stylesheet.

I want this too. Opting-in using !duplicate or some other syntax makes the user think about it. Not requiring an opt-in causes huge surprise when the stylesheet bloats like using mixins. I think we have reached the boundary where @extend can be implemented in a preprocessor without being a leaky abstraction.

I'd rather focus our education efforts here than on complex work-arounds for @extend in @media.

There is going to be education required no matter how we tackle this problem.

@at-root (without: media) { & { extend .something; }} removes the runtime context so that the extend operation can be performed as if it were not within a media context. This is useful in places where the base definition is a constant across all media definitions or is appropriately overridden via the cascade even when applied across media types.

This doesn't scope the definition to the media query, though, which I think is what users are trying to express. Ensuring that the properties cascade so that a top-level extension works out is complicated and contingent on the specifics of the user's CSS.

I want this too. Opting-in using !duplicate or some other syntax makes the user think about it. Not requiring an opt-in causes huge surprise when the stylesheet bloats like using mixins. I think we have reached the boundary where @extend can be implemented in a preprocessor without being a leaky abstraction.

I agree that the abstraction is still leaky, but !duplicate (or whatever) makes it less leaky, and there's value in that. @extend is how users expect to be able to express this -- we have ample evidence of that from the volume of requests we get for it to work.

I really appreciate the points on both sides here, and I think they're
making the argument for extend with a flag very strong. It's a syntax that
users expect, and the code result proposed is no larger than any equivalent
code produced by at-root.

I agree with Nathan that users (like myself) specifically want to extend
the styles but scope them to the query. I can imagine a couple ways of
creating mixins with at root that would accomplish this, but none so direct
or understandable as processing at the Sass level with extend.

On Monday, February 24, 2014, Nathan Weizenbaum [email protected]
wrote:

@at-root (without: media) { & { extend .something; }} removes the runtime
context so that the extend operation can be performed as if it were not
within a media context. This is useful in places where the base definition
is a constant across all media definitions or is appropriately overridden
via the cascade even when applied across media types.

This doesn't scope the definition to the media query, though, which I
think is what users are trying to express. Ensuring that the properties
cascade so that a top-level extension works out is complicated and
contingent on the specifics of the user's CSS.

I want this too. Opting-in using !duplicate or some other syntax makes
the user think about it. Not requiring an opt-in causes huge surprise when
the stylesheet bloats like using mixins. I think we have reached the
boundary where @extend can be implemented in a preprocessor without being
a leaky abstraction.

I agree that the abstraction is still leaky, but !duplicate (or whatever)
makes it less leaky, and there's value in that. @extend is how users
expect to be able to express this -- we have ample evidence of that from
the volume of requests we get for it to work.

Reply to this email directly or view it on GitHubhttps://github.com//issues/1050#issuecomment-35961979
.

Rob Wierzbowski
@robwierzbowski http://twitter.com/#!/robwierzbowski
http://github.com/robwierzbowski
http://robwierzbowski.com

You both seem to be thinking that I'm disputing the use case. I'm not. I simply think that it's not a direction sass should go. I think the implementation is very tricky and the output is going to surprise users. even the ones who add the !duplicate flag because Sass says "Hey you gotta add the !duplicate flag to do this and it's going to copy all this stuff for ya".

Furthermore, I think Sass's set of existing abstractions enables users to accomplish this in "user space".

These are all the criteria that Nathan usually uses to justify not doing something and I'm usually the one arguing for Sass making things easier. I think he just likes to disagree with me. >_<

My thought is that there isn't a way with current abstractions to do what I and other users are asking. Is there a way to create the behavior in #1050 (comment) with four breakpoints and twelve collumns? I don't think a matrix of mixin-utilizing extends for each viewport and widths combination used (12col-to-6col-to-3col, 12col-to-12col, 8col-to-4col-pushed-2col-to-6col, etc.) is a realistic solution.

@robwierzbowski Yes. As long as you can name each break point. Mixins, at-root, and extend are powerful enough to express the exact behavior that is desired. I guess I need to write a Sass library that demonstrates how.

Furthermore, I think Sass's set of existing abstractions enables users to accomplish this in "user space".

This is the crux of the issue for me. The user-space solution you're suggesting is complex and requires a large-scale restructuring of the surrounding Sass to make it work. Users are looking for a drop-in solution and you're proposing a full refactoring of their stylesheets. We have the power to provide precisely the semantics they're asking for; we can't do it for free, but I think conditionally adding bloat is a better compromise than trying to teach everyone a refactoring technique that it seems like no one but you understands.

We have the power to provide precisely the semantics they're asking for

Well, the semantics I'm seeing asked for don't make sense to me. Sometimes it acts like extend and sometimes it acts like include. I very much dislike this. The most important aspect of @extend is that is preserves the function of the cascade. The proposal on the table here is to copy things to the location of the @extend statement -- this is going to change the cascade and makes the implementation complex because the extend step now has to do a lot more than selector rewriting.

Instead, I think a solution would need to add @media directives all over the document -- wherever an extended selector is found; just like we do with selectors now.

An example:

.a { prop1: value1; }
.b { prop2: value2; }
@media (...phone...) { .c { @extend .a; prop3: value3; } }
@media (...tablet...) { .d { @extend .b; prop4: value4; } }
.e .a { prop5: value5; }

would compile to:

.a { prop1: value1; }
@media (...phone...) { .c { prop1: value1; } }
.b { prop2: value2; }
@media (...tablet...) { .d { prop2: value2; } }
@media (...phone...) { .c { prop3: value3; } }
@media (...tablet...) { .d { prop4: value4; } }
.e .a { prop5: value5; }
@media (...phone...) { .e .c { prop5: value5; } }

The implementation of this is a lot less complex as well.

Sometimes it acts like extend and sometimes it acts like include.

Newcomers to Sass don't understand the difference or why it matters.

The most important aspect of @extend is that is preserves the function of the cascade.

Again, most users don't understand this. All they understand is that it consolidates selectors, which means more compact CSS to them (though this isn't always the case). Users are disappointed that code like this doesn't work:

%clearfix {
    /* clearfix stuff */
}

.one {
    color: blue;
    @extend %clearfix;
}

.two {
    color: green;
    @media (min-width: 50em) {
        @extend %clearfix;
    }
}

.three {
    @extend %clearfix;
}

.four {
    color: orange;
    @media (min-width: 40em) {
        @extend %clearfix;
    }
}

The normal expectation is that it would generate something like this:

.one, .three {
    /* clearfix stuff */
}

.one {
    color: blue;
}

@media (min-width: 50em) {
    .two {
        color: green;
        /* clearfix stuff */
    }
}

@media (min-width: 40em) {
    .four {
        color: orange;
        /* clearfix stuff */
    }
}

To propose sprinkling extra media queries everywhere is the exact opposite of what users expect when they use extend (smaller CSS). Easier to write doesn't make for a good experience. Would adding a LESS-style include (where classes are also mixins with no arguments) really be that bad? I don't think anyone cares what it's called (extend vs include vs copy-it-here-because-i-said-so), they just want the behavior.

Sass isn't only for newcomers. Preserving source order at the expense of a
little more markup is a positive trade IMO.

Rob Wierzbowski
@robwierzbowski http://twitter.com/#!/robwierzbowski
http://github.com/robwierzbowski
http://robwierzbowski.com

On Wed, Feb 26, 2014 at 9:57 AM, cimmanon [email protected] wrote:

Sometimes it acts like extend and sometimes it acts like include.

Newcomers to Sass don't understand the difference or why it matters.

The most important aspect of @extend https://github.com/extend is that
is preserves the function of the cascade.

Again, most users don't understand this. All they understand is that it
consolidates selectors, which means more compact CSS to them (though this
isn't always the case). Users are disappointed that code like this doesn't
work:

%clearfix {
/* clearfix stuff */}
.one {
color: blue;
@extend %clearfix;}
.two {
color: green;
@media (min-width: 50em) {
@extend %clearfix;
}}
.three {
@extend %clearfix;}
.four {
color: orange;
@media (min-width: 40em) {
@extend %clearfix;
}}

The normal expectation is that it would generate something like this:

.one, .three {
/* clearfix stuff /}
.one {
color: blue;}
@media (min-width: 50em) {
.two {
color: green;
/ clearfix stuff /
}}
@media (min-width: 40em) {
.four {
color: orange;
/ clearfix stuff */
}}

To propose sprinkling extra media queries everywhere is the exact opposite
of what users expect when they use media queries (smaller CSS). Easier to
write doesn't make for a good experience. Would adding a LESS-style include
(where classes are also mixins with no arguments) really be that bad? I
don't think anyone cares what it's called (extend vs include vs
copy-it-here-because-i-said-so), they just want the behavior.

Reply to this email directly or view it on GitHubhttps://github.com//issues/1050#issuecomment-36133080
.

Sometimes it acts like extend and sometimes it acts like include.

Does it make sense to add a separate, media query-friendly include directive?

Newcomers to Sass don't understand the difference or why it matters.
All they understand is that it consolidates selectors

@cimmanon, Whether or not they understand that there is a fundamental theory behind @extend is irrelevant. There is, and that theory is what makes it work consistently in practice for all of our users.

To propose sprinkling extra media queries everywhere is the exact opposite of what users expect

I get it and it's why we're talking about it. But I'm ok with things not matching expectations as long as there is a clear explanation that will help them understand. It is easy to construct an example where the output that was originally suggested would differ from the behavior that is implied by the source code.

Does it make sense to add a separate, media query-friendly include directive?

Not to me. I don't see a new fundamental abstraction here. Ultimately, if we ever make an optimizer, it could clean up this output and coalesce media queries according to heuristics, optimization levels, etc.

If I understand it correctly, I'm all for Chris's last suggested
implementation. Sounds like exactly what I'd expect, and would be crazy
useful.

Rob Wierzbowski
@robwierzbowski http://twitter.com/#!/robwierzbowski
http://github.com/robwierzbowski
http://robwierzbowski.com

On Wed, Feb 26, 2014 at 11:45 AM, Chris Eppstein
[email protected]:

Newcomers to Sass don't understand the difference or why it matters.
All they understand is that it consolidates selectors

@cimmanon https://github.com/cimmanon, Whether or not they understand
that there is a fundamental theory behind @extend is irrelevant. There
is, and that theory is what makes it work consistently in practice for
all of our users.

To propose sprinkling extra media queries everywhere is the exact opposite
of what users expect

I get it and it's why we're talking about it. But I'm ok with things not
matching expectations as long as there is a clear explanation that will
help them understand. It is easy to construct an example where the output
that was originally suggested would differ from the behavior that is
implied by the source code.

Does it make sense to add a separate, media query-friendly include
directive?

Not to me. I don't see a new fundamental abstraction here. Ultimately, if
we ever make an optimizer, it could clean up this output and coalesce media
queries according to heuristics, optimization levels, etc.

Reply to this email directly or view it on GitHubhttps://github.com//issues/1050#issuecomment-36146497
.

To be clear, I'm not in favor of adding a flag here. If we're going to allow @extend within directives having a runtime dependency then we should just allow it. Furthermore, the strategy I outlined above works fine for @supports, @media, @page and even unknown directives.

Well, the semantics I'm seeing asked for don't make sense to me. Sometimes it acts like extend and sometimes it acts like include. I very much dislike this.

By "semantics", I was referring to the styling semantics: the relationship between the Sass stylesheet and how the page is styled, not the relationship between the Sass stylesheet and the generated CSS. In terms of styling semantics, the proposed flag brings @extend closer to the stated goal of "this element should be styled as though it also matches this selector".

Instead, I think a solution would need to add @media directives all over the document -- wherever an extended selector is found; just like we do with selectors now.

Sorry, I should have been clearer: this is what I'm arguing for. I didn't read @Snugug's example closely enough to figure out that it wasn't identical to this.

To be clear, I'm not in favor of adding a flag here. If we're going to allow @extend within directives having a runtime dependency then we should just allow it. Furthermore, the strategy I outlined above works fine for @supports, @media, @page and even unknown directives.

I think a flag is important to avoid users having massive unexpected bloat, although I'm open to being convinced otherwise.

Sorry, I should have been clearer: this is what I'm arguing for. I didn't read @Snugug's example closely enough to figure out that it wasn't identical to this.

👊

I think a flag is important to avoid users having massive unexpected bloat

This is Sass's curse for many of it's features. I support flags that change behavior or imply making something succeed that would fail/warn otherwise. This just implies that the user understands what they are doing. They need to understand this once, but then we force them to type this flag for all eternity. I'd rather them just learn this by reading the output and asking "why?".

Another vote for this functionality.

There are hack workarounds, but they are troublesome with CSS frameworks like Bootstrap.

Are we any closer with this? I presume it's a case of not merging the media queries that contain @extends with the ones that don't? I doubt it's an easy feat either way.

I could really do with extending some utility classes (to maintain consistency above all) where it's otherwise awkward to use them in the markup and with the @<breakpoint> suffix.

+1

Any reason to make it pending?

Shame... is everyone just using css now? Why has this been problem so difficult to solve?

I will come back here in 2025 and it would be still pending... 👍

Complaing about issues is not how open source works...

Am I correct in understanding the basic design is that an @extend of a SASS rule which is within a media query causes an emission of N css rules where N is the number of the media queries which contain the @extended rule?

+1

Who's watching this video in 2019?

@nex3 @chriseppstein

I know that you guys are very very busy and I respect all the work the core devs are putting into this open source project, but it sure would be nice to get an update on an issue like this every now and then.

This issue has been pending for 6 years now, and the last response from a core dev has been from 3 years ago.

Any idea when we could expect this feature to be implemented, if at all?

Has this feature been planned to ship with any future version of Sass?

Is this feature on any road-map?

Judging by the comments and 👍s, it seems a rather popular feature, so I'd expect this to get a bit more priority...

Generally speaking, if there aren't updates on an issue, nothing has changed because we don't have time to work on it alongside everything else we have on our plates. It's also not really an efficient use of our time to go around updating every issue to periodically say "nothing has changed."

The absolute best way to express how important a feature is to you is to put forth the effort to specify and implement it. We have a thorough contribution guide, and I'm always happy to help review and help out any way I can.

I've started a bounty to encourage developers to look into this matter.

Everyone interested in seeing this feature implemented, please contribute:

https://www.bountysource.com/issues/1362183-allow-extend-across-media-queries

In case somebody needs a workaround, you can create a mixin and include it into the class that needs it.

@mixin fakeExtend {
  w: x;
}

.a {
  @include fakeExtend;
}

@media (min-width: 500px) {
  .b {
    @include fakeExtend;
  }
  .c {
    y: z;
  }
}

Has anyone found a solution in which I can extend an already defined class?

I am working with bootstrap and I want to create a class which inherits multiple classes. My idea is that in this what I am almost using classes in the html and controlling the media query. So:

@include media-breakpoint-up(sm) {
  .some {
      @extend .vh-100;
      @extend .position-sticky;
      @extend .top-0;
  }
}

Bootstrap has managed to create a lot of the classes to be breakpoint friendly, but not 100% of them and I need this.

Cheers.

Lack of this feature causes SCSS library authors to write everything as mixins rather than classes, or as mixins and classes (library example). When a library doesn't prioritize mixins, flexibility suffers. Supporting opt-in duplication in @extend would provide more flexibility to library consumers.