Don’t recognize extendable selectors outside of @media contexts

[scottkellum]

Sass 3.2 is throwing this error:

DEPRECATION WARNING on line 20 of /Users/scottkellum/Sites/Singularity/framework/example/sass/oocss-responsive.scss:
  @extending an outer selector from within @media is deprecated.
  You may only @extend selectors within the same directive.
  This will be an error in Sass 3.3.
  It can only work once @extend is supported natively in the browser.

for this code:

@mixin foo {
  .foo {
    width: 100%;
  }
}

@include foo;

@media (min-width: 20em) and (max-width: 40em) {
  @include foo;
  .bar {
    @extend .foo;
  }
}

It seems like Sass should be ignoring the selectors outside the @media context for this new @extend behavior and result in no errors.

[chriseppstein]

Can I see a concrete use case instead of foos?

Hunt & pecked on my iPhone... Sorry if it's brief!

On Jul 23, 2012, at 1:19 AM, Scott Kellumreply@reply.github.com wrote:

Sass 3.2 is throwing this error:

DEPRECATION WARNING on line 20 of /Users/scottkellum/Sites/Singularity/framework/example/sass/oocss-responsive.scss:
 @extending an outer selector from within @media is deprecated.
 You may only @extend selectors within the same directive.
 This will be an error in Sass 3.3.
 It can only work once @extend is supported natively in the browser.

for this code:

@mixin foo {
 .foo {
   width: 100%;
 }
}

@include foo;

@media (min-width: 20em) and (max-width: 40em) {
 @include foo;
 .bar {
   @extend .foo;
 }
}

It seems like Sass should be ignoring the selectors outside the @media context for this new @extend behavior and result in no errors.

---

Reply to this email directly or view it on GitHub:
#456

[scottkellum]

line 45 and 53 here: https://github.com/scottkellum/Singularity/blob/master/stylesheets/singularitygs/_mixins.sass#L53

Having a compile choke in a @media environment due to a loose selector outside of that @media environment seems counter intuitive to the new isolated @media extending behavior. I assumed this was just a bug in the code throwing the warning as isolated environments wouldn’t care about selectors outside of that environment.

[nex3]

I'm not convinced this a bug. If a user uses @extend inside @media, they may well be expecting it to extend matching outer selectors as well. If it fails silently to do that, it could result in very confusing behavior.

[scottkellum]

I think you guys need to be extremely explicit about how you want extends to behave and follow through on that. Totally understand this is a complex issue, but to me this is more confusing as a user to have something that is isolated pop up a warning for matching code in explicitly different contexts.

RWD requires flexibility of multiple contexts and extend is the only way to consolidate selectors attached to styles. It is extremely difficult to implement extends consistently in a RWD context.

[nex3]

We have a very clear idea of how we want @extend to work. Unfortunately that's not always possible given the realities of CSS.

In this case, we want .foo {a: b} @media screen {.bar {@extend .foo}} to cause .bars to be styled as .foos only on screen devices. But CSS lacks the capability to express that without massive duplication of code and possibly destruction of specificity, so we need to decide what to do to work around that. We can't just have it behave consistently with the espoused semantics for @extend, because those semantics break down. So we have to decide in what way they should break.

In general, I think it's a good idea to print errors when the actual behavior can't follow the expected behavior. This protects users who expect behavior consistent with the espoused semantics of @extend.

[scottkellum]

Sorry, maybe I didn’t make that clear. I do not want this behavior: .foo {a: b} @media screen {.bar {@extend .foo}}

Well, I am fine with that behavior, but the issue here is that the new behavior is not consistent. If the contexts are explicitly different then: .foo {a: b} .bar {@extend .foo} @media screen { .foo {a: b} .bar {@extend .foo} } should work fine and .foo {a: b} .bar {@extend .foo} @media screen { .bar {@extend .foo} } should throw an error saying it doesn’t know what .foo is in the context of screen.

If I explicitly place styles inside a context to extend I should be able to extend them, no? I shouldn’t have to change my whole naming scheme just to extend these.

I too can’t wait until this comes to browsers, but can we at least make it a somewhat useful feature in Sass? When used correctly it can save so much file size.

[chriseppstein]

I find it's actually quite hard to talk about these things using abstract class names like .foo. But it seems to me that this structure works for you in this case and produces no warnings:

.foo {
  @extend %screen-foo;
  a: b;
 }
@media screen {
  %screen-foo {
    c: d; //presumably this would have it's own properties.
  }
  .bar {
    @extend %screen-foo;
    e: f; //presumably this would have it's own properties too.
  }
}

[scottkellum]

Awesome, Thanks Chris. I will try plugging this in when I have a moment to really dive in. Thinking of a few more ways around the issue as well using Sass::script.

[nex3]

.foo {a: b} .bar {@extend .foo} @media screen { .foo {a: b} .bar {@extend .foo} } should work fine

The problem with this is that it's still pretty likely that the user intended the .bar inside the @media to extend the .foo outside it. If that is the user's intention, it should be an error.

[marcins]

We're running into this deprecation warning and issue with Compass sprites. For example this SCSS:

@import "sprites/*.png";

.icon {
    @include sprites-sprite(regular-icon);
}

@media (max-width: 768px) {
    .icon {
        @include sprites-sprite(small-icon);
    }
}

Will give you:

DEPRECATION WARNING on line 81 of sprites/*.png:
  @extending an outer selector from within @media is deprecated.
 [...]

Also if you include the sprite only in the media query and not at the top level it doesn't generate the class at all in the CSS and the image doesn't work.

Maybe we're just doing it wrong!

EDIT: Never mind, this should probably be a Compass issue not a SASS issue. See Compass/compass#617

I'll leave it here in case anyone else ends up here researching the same issue. Using this mixin fixed the issue for us: https://gist.github.com/3105369 (and my SCSS port: https://gist.github.com/3223921)

[chriseppstein]

While I find this behavior annoying, I still think it's the lesser of several evils. Closing.

[Hannes-III]

I am new to SASS and I just learned and saw the power of %placehoders. This is a much better way than using mixins for repeating code.

Today I first saw this Warning "@extending an outer selector from within @media is deprecated" and I was very disappointed because of the mentioned "This will be an error in Sass 3.3".

If one uses it the wrong way it will not work, but if someone knows what he is doing, this is a great way to reduce size of compiled CSS.

By turning the warning into an error, you protect the bungling at a very high cost, by limit the gifted.

You asked for some example code. I made a mixin recently which I wanted to discuss. Let's see, if I am gifted or should be protected ;-)
My mixin was made to show the background of a susy header or footer or whatever over the full width of the parent container.
I hope that this can prove @extend in @media is quite important:

@mixin banner-bg($height, $bgColor, $opacity:null, $extends:null) {

    &%xxx{
        height:$height;
        background-color: $bgColor;
        @if $extends != null {@extend #{$extends} }
    }

    @extend %xxx;
    @extend %bannerbg;

    &:before{
        @extend %xxx;
        @if $opacity != null {@include opacity($opacity);} 
        content: "";
        position: absolute; 
        right: 0; 
        left: 0; 
        z-index:-100; 
    }
}

The Placeholder %xxx causes this strange warning, although it is 100% sure that the two elements that use that Placeholder will be in the same @media section. I do not understand why this should be prohibited.
And ask you to rethink changing this to an ERROR and keep it as a WARNING.

[chriseppstein]

Every time you include this, you're re-using the same %xxx placeholder? Placeholder classes are not ephemeral, they are like css classes and they have the same meaning across the stylesheet, just like a class would. The media query issue aside, I'm fairly certain this doesn't give you the output you want. To get the behavior you're thinking you want, you need to to use a unique placeholder class each time.

However, reliably creating a unique identifier is hard, so I had to write some ruby to do this.

Here is your code, working without warnings and without relaxing our error condition:
https://gist.github.com/chriseppstein/9a9e557412cc4afb67b6

All that said, I think this is compelling enough to add a unique identifier generation ability to Sass so I've created #771 to track that.

[Hannes-III]

Placeholder classes are not ephemeral

OK, when I wrote my comment I was pretty sure, that someone would proof that I am bungling and not gifted ;-).
I Agree, good Idea to make it an Error. Protect those like me, whose testcases also fail. I thought the mixin would work.
UniqueIdentifier Generator, good Idea!
Thank you for your suggestion on
https://gist.github.com/chriseppstein/9a9e557412cc4afb67b6

I have some comments still, I write them over there.

[chriseppstein]

Note: In #774 we have proposed a new directive (@at-root) that would allow @extend to be called from outside the media query even when within the scope of a media query. I think this allows for the valid, advanced use cases that are not currently met for using @extend and getting this warning.

[ntreadway]

I used @mixin to resolve this warning:

 @mixin respond($size, $type: min-width) {
     @media only screen and ($type: $size) {
       %c-col {
          margin-right: $column;
          margin-left: $column;
        }
       @content
      }
  }

@include respond($size: 40em){
   .c-sm-1 {
     width: 25%;
     @extend %c-col; 
   }
 }

Not sure if it's the best approach but thought I would share.

[WillsB3]

This behaviour is preventing us from what I see as a valid use case for using @extend within a media query. We are using Glue (with some modifications to generate a scss file instead of css) and style our icons up like this:

.social-link--facebook .social-icon {
    @extend .sprite-sprites-share_facebook;
}

Now, this works fine... Until you need to show a different icon for a different viewport size for example:

@media only screen and (max-width: 767px) {
    .social-link--facebook .social-icon {
        @extend .sprite-sprites-share_facebook;
    }
}

Is there anything we can do to work around this? I tried the mixin suggested by @ntreadway above but that didn't seem to work.

[lolmaus]

@scottkellum, @WillsB3, it seems that Sass maintainers just don't want us to be able to do that. :(

I also tried to bring this problem up (i'm sorry for creating a duplicate issue). I suggested that Sass should maintain a separate extendable list of selectors for each unique media query. But @chriseppstein considers this to be counter-intuitive for many users.

@chriseppstein points out that Sass does allow to extend from media queries. To do this, you have to declare a separate extendable selector for each unique media query, so that the extended value wasn't found outside the media query. This can be done either manually or using a technique called "Maps, Media & Extend, Oh my!".

Basically, the "Oh, my" technique requires that:

• all extendable selectors should be declared:
  • from within an initialization mixin,
  • via @at-root directive,
  • with an interpolated media query name within each selector's name;
• you have to maintain a global table of what extendables have been initialized for what media queries;
• you have to call the mixin prior to each @extend call.

Oh my, it's so intuitive that i'm still not sure whether i correctly understand what's going on in that example. So you can correct me if you grasped it better.

---

Well, this is the direction where modern Sass is heading for. Another example of the tendency is the way parent selector can be interpolated.

In LESS and Stylus you can do:

.fieldset {
  background: red;
  &-field {
    background: blue;
    &-label {
      background: green; }}}

To achieve the same result in Sass, you have to do:

.fieldset {
  background: red;
  @at-root #{&}-field {
    background: blue;
    @at-root #{&}-label {
      background: green; }}}

I guess that if you choose Sass over other preprocessors then you just have to accept that "intuitive" means not "intuitive from the perspective of users" but rather "from the perspective of the internal logic of the Sass compiler".

[nex3]

It's very easy to come up with individual examples to justify all kinds of behavior, but that doesn't mean the behavior is good for the ecosystem in general.

This issue in particular is thorny because the ideal behavior just isn't possible for a preprocessor. The semantics of @extend simply cannot be satisfied across media queries without violating the user expectation about how many selectors will be generated. Following this expectation is very important; the size of the generated stylesheet concerns users a great deal, both from a bandwidth perspective and for staying within IE's selector limit. Many users use @extend specifically because it produces more compact output than mixins. We cannot silently multiply the size of their selectors based on the context in which they use @extend.

There's been a lot of discussion about this, here and elsewhere, but really what it all boils down to is "I wish I could do it." I wish that too. But it's not enough to want it; it has to be possible. In all this discussion, I've seen practically no one* address the issues preventing us from making this work. If you want to use @extend in media queries, tell us how to make it work. We're all ears.

* With the notable exception of @rachelnabors who suggested the current scheme of allowing @extend in media queries as long as it didn't reach outside them.

[lolmaus]

@nex3 Say, a user wants to extend from a media query. Consider @WillsB3's use case as an example. As extending from media queries is impossible, what workaround will he use? What does everybody use in this situation?

Mixins. It's the only thing that works.

I find these in all my projects:

=background-foo
  background: url(foo.png) pink

%background-foo
  +background-foo

This looks redundant and it is. But i'm forced into having both mixins and extends implementations of snippets because i need them inside media queries.

The mixins workaround produces a CSS much larger than the proposed functionality of extends "silently multiplying the size of their selectors", because each mixin usage will have a duplicate rule in CSS, whereas each extend will only have a single duplicate per media query.

Say, you have three different media queries and you're trying to extend four times in each of them and four times outside media queries. The suggested extends approach will produce 4 CSS rules and the mixin workaround will produce 13.

So basically:

1. You say you don't want to implement this because you care for resulting CSS size. But by rejecting to implement it you doom people who need it into multiple times larger CSS size.
2. You neglect the demands of people who use extends extensively and instead care about newbies who might eventually extend from a media query without knowing the mechanism and wonder why there's a duplicate rule in CSS.

Please reconsider.

PS There's of course the "Oh, my" workaround (see above), but it does absolutely the same: producing a unique extendable for each media query. It's the same what we ask here, but with absolutely ridiculous usage complexity.

[nex3]

@lolmaus The issue isn't just the output size in an absolute sense; in general, people tend to overestimate the impact of duplicated text and underestimate the effectiveness of gzip compression_. The primary issue is the ability of users to reason about what their output will look like. Both the mixin solution you describe and Chris's solution have the extremely valuable advantage of _making the functioning of the compiler explicit*.

When a user writes @include background-foo they know that that's going to copy the styles rather than move around their selectors, because they're explicitly requesting it. If we just allowed @extend to silently behave very differently when used across media queries, it would be doing something the users didn't expect and didn't intend. Even if often that will have the same result as what they tried, it won't always, and that's a problem.

You're also underestimating the degree of extra text that would be generated if we silently copied selectors. In addition to the selectors being extended, the full media query would need to be copied in order to preserve the order that the selectors were defined in (which is clearly important). For example:

%foo {color: blue}

.foo {@extend %foo}
.bar {color: red}

@media screen {
  .baz {@extend %foo}
  .qux {color: green}
}

would need to be compiled to

.foo {color: blue}
@media screen {.bar {color: blue}}

.bar {color: red}

@media screen {.qux {color: green}}

* This quirk of estimation means that generating more output than users expect will make them very unhappy, but generating large amounts of output that they do expect won't cause many problems.

[lolmaus]

The primary issue is the ability of users to reason about what their output will look like.

Oh come on! Sass @extend is counter-intuitive in the first place. Common users don't understand how it works. Here's the most recent example, just five days ago: #1038 The same question arises on Stackoverflow every week. The main feature of it is that users don't understand what is going on with their code and blame Sass to be buggy. Even though it is described explicitly in documentation.

But there's more than that. I believe that most users just don't even notice that their incorrectly extended selectors become bloated, simply because it doesn't break the looks.

So my point is: if you use extends, you should either get your ass to learn how it works or just accept the fact that the convenience of using @extend may result in not the shortest CSS possible.

Sass 3.3 introduces a lot of new stuff, some of it is far from being intuitive. Why do you expect that common users will be quick to grasp @at-root #{&}-mymodule (while it's simply &-mymodule in Less and Stylus), and at the same time be unhappy with the fact that @extend inside media queries doesn't fail anymore?

I believe that if Sass 3.3 introduces an ability to extend from within media queries, it will not make anyone unhappy with the size of their CSS. If a user is advanced enough to care about the size of generated CSS, it won't be hard for him to learn how Sass 3.3 extends work.

PS Ain't Sass 3.3 capable of merging identical media queries yet? Is there an issue ticket for that already?

[Snugug]

@lolmaus There is a Latin phrase that I think sums up the counter-point to your argument: Ignorantia juris non excusat or "Ignorance of the law does not excuse". Suggesting that it's OK to codify bad behavior because people don't know any better is a terrible suggestion made worse by the rude delivery. I, and many fellow framework developers, know exactly how @extend works and work hard to optimize our code around its benefits. Extension, especially in a pre-process language, is tricky as hell (as evidenced by the fact that really only the Ruby implementation of Sass gets it right of all CSS Preprocessors, and that's because it's caught most of the edge cases already and takes hard lines against bad output). When used properly, extension can actually produce CSS that's smaller than you would write by hand as you're able to micro-optimize in a system where otherwise you wouldn't think to. Your argument that "it's cool cause no one looks at their output CSS anyway" is a terrible and misleading one, missing the point of @nex3's argument against; it's about predictability of and a silent change in the way an interaction happens, not necessarily the actual duplicated code.

As for your tangent into other features of Sass 3.3, while @at-root is more verbose, it's much more predictable (again that word) than the way it's handled in Less and Stylus. It also provides users with options and can be used in more places than just interpolating a nested selector, providing a consistent and predictable (again) interface for referring to the root of a document. Merging identical media queries? As stated time and time again by @nex3 and discussed at length in #241, re-ordering media queries is dangerous and (gasp) unpredictable. Instead, a direct approach (@target) has been proposed.

One of the key aspects of User Experience (of which Developer Experience, what we're talking about, falls under) is that actions should have predictable outcomes. On a website, if a red button had the text "Free Shipping" and if clicked on a product page, it provided free shipping, but if clicked on from an item in a carousel shipping was $5 because somewhere in the business logic of that button it's only free from a product page, people would be pissed off. The argument is for making the "Free Shipping" button always mean "Free Shipping" and if shipping isn't free, make sure the user explicitly knows.

[Snugug]

Speaking of Free Shipping, @nex3 @chriseppstein thoughts on providing a way for users to explicitly state that they wish a new extension context be created (i.e. duplicate the thing being extended and use that where appropriate)? 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.

[lolmaus]

@Snugug

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

Maybe you didn't undersand what i'm suggesting and that's why we have this argument...

I'm suggesting that a new extend context should be unconditionally created for every unique media query type. Within each such context, @extend should work as usual. Extends from different contexts should not be aware of each other.

This behaviour is absolutely predictable, it does not require Sass to do any decision making, it does not require rearranging selectors "to the first or last item", and the "normal @extend pattern" will still make perfect sense here.

---

Suggesting that it's OK to codify bad

If you consider this behaviour bad, please provide concrete examples and arguments. I provide mine below.

---

I, and many fellow framework developers, know exactly how @extend works and work hard to optimize our code around its benefits.

Currently Sass does not allow to extend the same selectors inside different media queries (or inside + outside a media query). It just doesn't work, and this fact has no benefit at all.

---

Your argument that "it's cool cause no one looks at their output CSS anyway" is a terrible and misleading one

I never did such an argument. My argument was: Let users do what is currently impossible. If they want to use it, they can read docs and learn how it will work for them.

If they're neglectful so much that they don't read, then they will hardly notice the difference. @nex3 cares about how users will be surprised by the change, but they are already misusing @extend all the time and most of them don't even notice it. Also, how can you be surprised by something you're not doing?

Let me empathize this. Nobody is currently extending same selectors within different media queries because it just doesn't work! Enabling this will not change the output of existing code.

Only people who read that extending same selectors from different media queries has been enabled in Sass 3.3 will start using it. And they will know how it works because they have just read it!

There also will be newbies who will ignorantly use extends in media queries without knowing how it works. But it will not hurt them because:

1. they will see in the browser exactly what they wanted;
2. resulting CSS size will not be larger than the mixin alternative;
3. the suggested behavior does not introduce new collisions of any kind or any unwanted behaviour (other than the fact that when you ask for an extend within a media query then you —surpise!— get an extend within a media query).

---

@at-root is more verbose, it's much more predictable

So why do people stumble on it all the time? Parent selector is probably the most misused feature in Sass 3.2. "Why does my &-foo not work" is the most popular question on Stackoverflow, with "Why does my #{&}-foo produce bloated markup" being close on the heels. Again, a lot of users just don't notice that their #{&}-foo produces bloated markup.

As for @at-root, it looks logical for Sass gurus who know Sass inside out, but it is counter-intuitive for normal users. And @chriseppstein's suggestion to consider parent selector's crazy behavior to be normal and to work around it with .foo, .bar { #{append-to-selector(&, ".baz")} {a:b;}} is ridiculous. No sane person (who's not a Sass maintainer/guru) will consider that to be intuitive.

I just don't understand why you let that counter-intuitive stuff pass and ban the possibility of extending from different media queries. It just does not make sense. :(

---

Merging identical media queries? re-ordering media queries is dangerous and (gasp) unpredictable

The @extend directive always merges selectors. So if Sass 3.3 produced a merged media query for each extend, it will not be unpredictable. Also, it will not break anything.

---

@extend %half !duplicate;
because it is an explicit call, a user will understand that they're changing how it works.

Because doing this without !duplicate will still be impossible, this is how users will feel when using !duplicate:

.foo
  @media (min-width: 500px)
    @extend %foo !yes-i-really-mean-it
    @extend %bar !please-master-i-really-need-to-do-an-extend-from-this-media-query
    @extend %baz !i-ploofing-know-what-i-m-doing-you-sparkling-sunflower

[nex3]

@lolmaus Please keep your language civil. I've edited out your profanity, and further cursing will result in me deleting your comments entirely. These discussions are public and I won't have them taking a tone that makes the community looks like a bunch of squabbling adolescents.

Having @extend silently ignore all selectors outside of the current directive context is a bad idea. Not only does it not match the user's expectation of the behavior or the semantics of extend, it does so without any indication of why or in what way it's failing. To a user who (reasonably) expects @extend to work across @media boundaries, it will look as though some of their styles work and some don't. They'll need to do serious debugging to figure out what's going on and why.

The idea that users already have trouble understanding how @extend works, so we shouldn't worry about making it harder to understand is deeply misguided. The fact that @extend is already complex indicates that we should do everything we can to make it predictable and straightforward, while preserving the semantics it was designed to provide. You're right that there are plenty of users who have trouble comprehending @extend, but there are plenty more who get it. Every time we make it more complicated, the set of people who get it gets smaller.

@Snugug Adding a flag for this behavior is certainly one way to allow a back door for users to be explicit. Feel free to file a separate issue about it where we can discuss it further.

[Hannes-III]

@nex3 I fully agree to what you said, there is nothing worse than a machine that does something because a User made a mistake. It should never ignore errors and keep the user thinking he did everything right. Meanwhile the Machine would have to do something that it thought that the user wanted to have. But How should the machine know?
I fully believe in the future of SASS, because the maintainers fight hard to keep up the Quality. As I said above: "protect the bungling!"