New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow @extend across media queries #1050

Open
Snugug opened this Issue Dec 16, 2013 · 67 comments

Comments

Projects
None yet
@Snugug
Contributor

Snugug commented Dec 16, 2013

Edit: The current plan here is to allow @extend across media queries by duplicating the queries the current @extend is in and unifying them with any media queries the extendee is in. For example:

.a {w: x}
@media (min-width: 500px) {
  .b {@extend .a}
  .c {y: z}
}

would produce

.a {w: x}
@media (min-width: 500px) {
  .b {w: x}
}

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

and

@media screen {
  .a {w: x}
}

@media (min-width: 500px) {
  .b {@extend .a}
  .c {y: z}
}

would produce

@media screen {
  .a {w: x}
}
@media screen and (min-width: 500px) {
  .b {w: x}
}

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

Original issue follows:


As originally brought up in #456, one way to allow extending across media queries would be to have a flag for @extend to explicitly tell Sass that you're OK with creating a duplicate context in a similar fashion to how the !optional flag currently works.

The syntax as currently proposed would look/work something like the following:

%full {
  width: 100%;
  float: left;
  clear: both;
}

%half {
  width: 50%;
  float: left;
}

.sidebar-1 {
  @extend %full;
  background: blue;
  @media (min-width: 500px) {
    @extend %half !duplicate; // A new extend context will be created here for the all, min-width: 500px media context and extension will work as normal.
    background: red;
  }
}

.sidebar-2 {
  @extend %full;
  background: green;
  @media (min-width: 500px) {
    @extend %half !duplicate; // Because a context for this exact media query already exists, it will extend that one instead of creating a duplicate context
    background: orange;
  }
}

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

would compile to

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

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

.sidebar-1 {
  background: blue;
}

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

  .sidebar-1 {
    background: red;
  }
}

.sidebar-2 {
  background: green;
}

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

.content {
  background: purple;
}

Of course the optimization around this would be difficult, needing to ensure that the matching only happens for identical @media contexts (but include ones in or chains) and a decision would need to be made as to if the selectors should be moved to the first or last item as the normal @extend pattern of "all" doesn't quite make sense here, but because it is an explicit call, a user will understand that they're changing how it works.

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Dec 29, 2013

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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Dec 30, 2013

@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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Jan 6, 2014

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.

@Snugug

This comment has been minimized.

Contributor

Snugug commented Jan 6, 2014

@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.

@emagnier

This comment has been minimized.

emagnier commented Jan 6, 2014

+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.

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Jan 6, 2014

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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Jan 7, 2014

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.

@nex3 nex3 reopened this Jan 7, 2014

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 24, 2014

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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Feb 24, 2014

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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 24, 2014

@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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Feb 24, 2014

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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 24, 2014

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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Feb 25, 2014

@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.

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Feb 25, 2014

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 notifications@github.com
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

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 25, 2014

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. >_<

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Feb 25, 2014

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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 25, 2014

@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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Feb 26, 2014

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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 26, 2014

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.

@cimmanon

This comment has been minimized.

cimmanon commented Feb 26, 2014

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.

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Feb 26, 2014

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 notifications@github.com 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
.

@lolmaus

This comment has been minimized.

lolmaus commented Feb 26, 2014

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

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

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 26, 2014

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.

@robwierzbowski

This comment has been minimized.

Contributor

robwierzbowski commented Feb 26, 2014

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
notifications@github.comwrote:

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
.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 26, 2014

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.

@nex3

This comment has been minimized.

Contributor

nex3 commented Feb 27, 2014

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.

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Feb 27, 2014

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?".

@luksak

This comment has been minimized.

luksak commented Aug 18, 2015

I totally agree with @nex3.

Having this feature is much more important than caring about bloat that only affects non-gzipped CSS.

I also think that hand-optimized CSS is important, but in that case you might not use this feature, right?

Post-optimization is definitely possible. The question is how good it will be while staying safe.

@chriscartlidge

This comment has been minimized.

chriscartlidge commented Dec 11, 2015

👍

@mattidupre

This comment has been minimized.

mattidupre commented Jan 13, 2016

Was looking for a workaround and stumbled on benschwarz/metaquery. TL;DR: use Javascript to apply classes to instead of media queries.

Otherwise I completely agree that this issue should be worked out. @extend is a huge chunk of SASS functionality, and at the point where developers really care that much about file size they will be smart enough to optimize a different way.

@ruanmer

This comment has been minimized.

ruanmer commented Feb 5, 2016

+1

@vandres

This comment has been minimized.

vandres commented May 27, 2016

+1

@t22james

This comment has been minimized.

t22james commented Jul 18, 2016

noticing that this ticket has very teasingly been given a 'planned' label... do we have any update of timelining for release?

@chriseppstein

This comment has been minimized.

Member

chriseppstein commented Jul 20, 2016

@t22james we have a design, but it's not slated for any release at this time.

@matthewmorek

This comment has been minimized.

matthewmorek commented Jul 27, 2016

@chriseppstein Please, keep us updated on the progress, as there are a lot of us waiting for this feature to be added to Sass as soon as this is possible.

@sospedra

This comment has been minimized.

sospedra commented Sep 21, 2016

3 years later still not done...

@brandensilva

This comment has been minimized.

brandensilva commented Oct 4, 2016

Many of us are still waiting on this feature to land. It seems like with all the discussion previously around this it'd have some more weight in its priority.

The fact that you can't @extend from within a media query feels awkward. Can you generate mixins and workarounds? Sure, but you just expect it to work no matter where you @extend from as long as whatever you are extending is available to the file you are using it in.

@nagyalex

This comment has been minimized.

nagyalex commented Jan 4, 2017

Another vote for this functionality.

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

@JakClark-SpiralMedia

This comment has been minimized.

JakClark-SpiralMedia commented Jan 12, 2017

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.

@liuliangsir

This comment has been minimized.

liuliangsir commented Feb 9, 2017

+1

@jimmyko

This comment has been minimized.

jimmyko commented Sep 19, 2017

Any reason to make it pending?

@imdevan

This comment has been minimized.

imdevan commented Oct 8, 2018

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

@4hmedSamir

This comment has been minimized.

4hmedSamir commented Oct 10, 2018

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

@luksak

This comment has been minimized.

luksak commented Oct 10, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment