Should you use a Sass mixin or @extend?

If you want to DRY your CSS, the easiest way is to start using a pre-processor like Sass. Specially in the beginning though, you need to regularly look at what your Sass compiles to. By using mixins for instance, you can seriously scale back the amount of code you need to write. But if you don’t know how things compile, you’ll end up with DRY Sass and bloated CSS. Since that’s what gets send to the user agent eventually, you should try to prevent that.

Let me illustrate what goes wrong with a simple example (this code visually hides some text while keeping it available to alternative user agents, such as screen readers):

That looks like pretty clean Sass, right? Until you look at the compiled CSS:

So much for not repeating ourselves. Imagine doing this with embedded files for instance, using the inline-image() Compass helper, and you’re in serious trouble.

The better solution

In this case using a %placeholder and @extend would have produced less CSS, with the same number of selectors (so it doesn’t make a difference in hitting the IE selector limit):

Which gets us this CSS:

Ain’t that nice and clean!

So when should you use a mixin?

When you want the output of the mixin to change depending on how you call it. If you need to take arguments or a @content block, a placeholder isn’t going to help you. Here’s an example:

It’s a subtle difference when writing Sass, but it can make a huge difference in your compiled CSS. Any questions, let me know in the comments and I’ll try to answer them.

  • Gabriel

    Thanks !

  • Guest


    @extends are really useful. But, do you know how many selectors (comma separated) a browser can deal with? Suppose that we have a %font-abc, and this guy is used by several selectors. The output code will be like .a1, .a2, .a3 (…), .z999 { … }.

    • Roy Tomeij

      Sorry for missing this one. I have no idea, but thousands at least I’d say.