@extend is not the devil

[iamcarrico]

First off, I am going to say I had an irrational anger at the article posted in December. This is partially a reply to that, while also explaining why the prohibition of @extend in the Sass Guidelines is foolish. That being said, I am not here to say that @extend should be used all the time, but merely that there are many reasons why it should be used within a project.

TL;DR: @extend has a place in our hearts and stylesheets, but certainly isn't the end-all

Where are @extends helpful?

Chunky bacon! Chunky bacon!
— Why

There are two big places I find using @extend is most helpful. First off, for components, and components that might need repeating. I emphasize the might here, because although we set this up on all our work, we don't use it for each one. For every component we make, we create a silent extend class that can be used in other elements further along. I will admit, part of this comes from working within the Drupal ecosystem, where we find we have to @extend a large set of styles on another class, because it is impractical to change the classes/markup. It would also be impractical to change all of a bit of styling we have done into a mixin just for something that is found much later on.

Second, for base styles that are replicated often. The core example I always use for this are buttons. Why? Because we use buttons all the bloody time, and for most of our sites, they use the exact same base stylings. The need for a mixin that repeats those stylings is not needed, and can easily "dirty-up" the code base. Now, I can see you from here going "BUT GZIP!"...

BUT GZIP

To assume makes an an 'ass' out of 'u' and me'
— The only way I remember how to spell assume.

We should never make assumptions on how other pieces of our ecosystem are setup, or where our code will end up next. This is a belief I hold very firm, especially if we are talking about guidelines on how to write Sass. Those who are getting the advice may not have the server knowledge, or even the ability to ensure their hosting environment is setup in this way— and as arbitrators of knowledge, we can suggest that they look into that, but we cannot rely out outside technology to solve our problems for us. We must, always, make our code as efficient as possible and suggest others do the same. I think back to when I was considering hosting my site on Amazon S3, which does not support sending of gzipped assets if you are using it as a static host. S3 is not alone in this, and many static hosts have similar... issues.

All this being said, yes— everybody should be using gzipping of assets. But just because we say that, doesn't mean we can say we don't have to write good Sass because of it.

Invisibility suits need silencing cones

Harry could not be seen, but Snape could hear the pitter-patter of somebody's shoes down the hall.
— Not a quote from Harry Potter

I was on a project a while back where mixins were being used to create a grid system. A single mixin was called like 10 times to re-build the entire grid system with different classes so that we had a huge amount of excess code. It was a bad idea, and I hated it from day 1, but the client wanted it. When we tried to @extend something out of it @extend .grid-1-2-of-5, there were vast unexpected consequences, as one would expect. This is not a good way of using @extend.

And then the actual grail came, %silent_extenders. These, these had some power. By using them, we remove any and all chances of having "unexpected consequences". We use each silent extender once, and only once, and when we extend one— we know exactly what will happen and where it will happen. IMHO, @exend should never be used on not a silent extend.

It is all about that {@media selector}

Wasn't that supposed to say bass? No trouble...

Yes, there is no way to use @extend within a media selector. There are huge amounts of reasons why, not least of which is it would produce unexpected consequences. This to me is a feature, not a bug and should be celebrated. 🎉

As a note, selectors that we are extending that do have @media directives in them WILL be extended as we would expect them. There is no issue with having a complex set of rules with @media involved being extended, we just cannot use @extend from within. http://sassmeister.com/gist/ddfe57c65a9d7042913a

Flexibility begets silliness.

Yes, @extends cannot accept arguments. That is what @Mixins are for. That doesn't mean we shouldn't use @extend.

Verbum Incarnatum

I suggest changing the wording from "To sum up, the @extend directive is prohibited." to describing where @exend should be used. I think that should be only with silent extenders, and judiciously. But to ban it outright is to ignore valid use cases.

[KittyGiraudel]

Hey Ian, thank you very much for your feedback. And what a feedback this is, you could make an article out of it. :)

I hope this styleguide did not offend you. As stated in the disclaimer, those guidelines are quite opinionated and you might agree or disagree with some rules. I am fine with that.

Now, you are right in some aspects: I should mention Gzip in the styleguides. I should also mention that when @extend is being used, it should be on silent placeholders that should only be used once and so on.

Let me open an issue so we improve the @extend section. :)

[chriseppstein]

A CSS project is no place for randomness.

1. Lots of people enjoy the random() function.
2. Extend is not random. It seems like you don't understand it, but that doesn't mean it is random.

[KittyGiraudel]

Randomness might not be the accurate word then. :)

I have spoken with quite a few people working on medium to large scale projects. None of them told me they were enjoying the @extend directive. All of them avoided it when possible.

[chriseppstein]

I have spoken to a few people about Sass too. Many of them used extend with good success when they did not go crazy with it.

[elyseholladay]

I have to agree with Chris. Having worked on two very large-scale Sass architectures for enterprise/e-commerce sites, I saw a lot of significant impact w/ @extend and despite some long selector lists, never had any problem with it. Did a test today and got a 1-2kb drop in file size w/ it, just for clearfix—something that I doubt will have significant impact on grouping. I think Ian makes some great points here. There are some places extends don't make sense, but they're still, IMO, very useful.

[jamadam]

I'm @hugogiraudel 's side :)

If I want to @extend, I would as follows.

@mixin clearfix() {...}

@media (max-width: 800px) {
    %clearfix {
        @include clearfix();
    }
    .foo {
        @extend %clearfix;
    }
    .bar {
        @extend %clearfix;
    }
}

It's acceptable "within a module" but I prefer "as little as possible."

[KittyGiraudel]

#31 closed by rephrasing the whole @extend section to make it lighter. Let me close this.

[KittyGiraudel]

Actually allow me a question: you tell me you do not take Gzip as a valid argument to exclude the @extend property. Fair enough, I hear your point.

Although I must assume you do not write your media queries within your selectors to prevent any media query duplication in the output, then. Am I right?