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
@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.
If you enjoyed reading this article, you may want to follow me on Twitter.
Want to learn more about Sass? Join me in Amsterdam on June 3, 2014!