Sass: Introducing mixins
Tagged as Web Workbench
The Mindscape Web Workbench supports Sass, giving intellisense, syntax highlighting, compilation and minification for Sass files inside Visual Studio. If you’re new to Sass you will find this post useful for understanding mixins in Sass — one of the many powerful reasons for using Sass over plain old CSS.
This article is based on Sass and Compass in Action, to be published spring 2012. It is being reproduced here by permission from Manning Publications . Manning early access books and ebooks are sold exclusively through Manning. Visit the book’s page for more information.
Introducing Mixins
When you’ve got a few small stylistic similarities throughout your site, colors and fonts that you use consistently, variables are a great way to keep track of them. But when your styles get more complicated, you need to be able to reuse more than just individual values. You need to reuse whole chunks of style. In Sass, you do this with mixins.
A mixin is defined using the @mixin rule. This looks just like any other CSS @ rule, like @media or CSS3′s @font-face. It gives a name to a bunch of styles, so that those styles can be easily reused throughout the stylesheet. The following Sass code defines a simple mixin for adding cross-browser rounded corners to a CSS rule.
@mixin rounded-corners { border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px; }
The mixin can then be used anywhere in the stylesheet using the @include rule. This takes all the styles in the mixin and puts them wherever it was @included. When you write
.notice { background-color: green; border: 2px solid #00aa00; @include rounded-corners; }
Sass turns it into
.notice { background-color: green; border: 2px solid #00aa00; border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px; }
The border-radius, -moz-border-radius, and -webkit-border-radius properties in .notice all came from the rounded-corners mixin. In this article, you’ll learn to use mixins to avoid repetition. With the use of arguments, mixins will even allow you to abstract out common patterns in your styles, so that they can be reused easily elsewhere. In fact, mixins are so useful it’s tempting to overuse them. Overuse can result in a large amount of generated CSS that’s slow to download. As such, we’ll start by learning which situations call for the use of mixins.
When to use mixins
Mixins allow you to easily share styles among different parts of the stylesheet. Any style you find yourself repeating from rule to rule would make a good mixin, especially when that style seems like a logical unit: a good group of properties that make sense to set together.
A good rule of thumb for knowing whether a group of properties would make sense as a mixin is whether you can come up with a good name. If you can find a nice short name that describes the style those properties bestow (like rounded-corners, fancy-font, or no-bullets), then they’d probably make a good mixin. If you can’t, maybe a mixin isn’t called for.
In some ways, mixins are a lot like CSS classes. Both let you name chunks of style, so it can be confusing when to use which. The most important distinction is that classes are meant to be used in your HTML, while mixins share styles within the stylesheets. This means that classes should be semantic, not presentational: they should describe the meaning of an HTML element, not how it looks. Mixins, on the other hand, should be presentational: they’re designed to describe how a CSS rule should look.
In the example above, .notice is a semantic class name. When an HTML element has class=”notice”, that describes the meaning of the element: it’s some sort of message for the user. The rounded-corners mixin, on the other hand, is presentational. It describes the visual style (specifically the corners) of whatever rule includes it.
Using mixins and classes together allows you to write clean HTML and CSS using semantic classes, while avoiding repetition using mixins. In addition to making your HTML and CSS easier to read and maintain, sticking to this distinction makes it easier to think about your styles as you’re writing them.
Sometimes it’s useful to put more than just properties into a mixin. Luckily, Sass allows you to put rules in mixins as well.
CSS rules in mixins
Mixins can contain more than just properties. They can also contain CSS rules, with selectors and properties of their own.
@mixin no-bullets { list-style: none; li { list-style-image: none; list-style-type: none; margin-left: 0px; } }
When a mixin containing CSS rules is @included in a parent rule, the rules in the mixin become nested within the parent. As an example, look at the following Sass code, which uses the no-bullets mixin.
ul#foo { font-size: 110%; @include no-bullets; }
Sass compiles this into the following CSS by expanding the @include into the contents of the mixin.
ul#foo { font-size: 110%; list-style: none; li { list-style-image: none; list-style-type: none; margin-left: 0px; } }
The rules within the mixin can even use the Sass parent selector, &. Just like when it’s used outside of mixins, it’s replaced by the parent selector when Sass unpacks the nested rules.
If a mixin contains only CSS rules and no properties, it can be included at the top level of the document, outside of any CSS rule. This isn’t very useful when you’re only writing mixins for yourself, but if you’re using a library like Compass, this is a good way of providing styles in a way that you can choose whether or not to use them.
Next, we’ll learn how to make mixins more flexible and reusable by allowing them to take arguments.
Passing arguments to a mixin
Mixins don’t have to always produce the exact same style. A mixin can take arguments that allow the @includer to customize the exact style the mixin produces. Arguments are just variables that are assigned to CSS values provided when the mixin is @included. If you’ve used JavaScript, this works just like a function.
@mixin link-colors($normal, $hover, $visited) { color: $normal; &:hover { color: $hover; } &:visited { color: $visited; } }
When the mixin is @included, arguments are passed just like they would be to a CSS function. When you write:
a { @include link-colors(blue, red, green); }
Sass turns it into
a { color: blue; &:hover { color: red; } &:visited { color: green; } }
When you’re @includeing a mixin, it can sometimes be hard to keep track of which argument means what and which order they go in. Because of this, Sass allows the arguments to be explicitly named by saying $name: value. Named arguments can go in any order, as long as they’re all present.
a { @include link-colors($normal: blue, $visited: green, $hover: red); }
Although it’s good to allow customizability for mixins with arguments, sometimes arguments can be a pain when you don’t need to customize. Thus Sass allows mixins to declare default values for their arguments.
Default argument values
Arguments can also have default values, which are used if the mixin isn’t passed enough arguments when it’s @included. Default arguments take the form $name: default-value. The value can be any normal CSS value, including other arguments.
@mixin link-colors($normal, $hover: $normal, $visited: $normal) { color: $normal; &:hover { color: $hover; } &:visited { color: $visited; } }
Now if someone does @include link-colors(red), $hover and $visited will automatically be red too. Mixins are only one of the features Sass has for making styles reusable.
Summary
Mixins allow Sass users to write semantic stylesheets while avoiding repetition of presentational styles. We learned not only how to use mixins to reduce repetition but when to do that so your stylesheets and CSS are as maintainable and semantic as possible.
3 Responses to “Sass: Introducing mixins”
Leave a Reply
Categories
BrainDump (1)
Community Code (4)
Events (16)
F# (14)
General (53)
Lab Samples (2)
LightSpeed (268)
MegaPack (8)
News (71)
NHibernate Designer (26)
Nightly news (52)
Phone Elements (24)
Products (87)
Projects (5)
Screencast (6)
SharePoint (3)
Silverlight (14)
Silverlight Elements (66)
SimpleDB Management Tools (20)
Visual Studio (9)
VS File Explorer (7)
Web Workbench (39)
WPF (44)
WPF Diagrams (57)
WPF Elements (110)
WPF Property Grid (32)



Posted by John-Daniel Trask on 18 December 2011 



[...] Sass: Introducing mixins (John-Daniel Trask) [...]
Great stuff! Integration with Visual Studio makes it so easy to use. Highly appreciate!
[...] One really powerful feature of the Less Web stylesheet language is mixins. A Less mixin, like a Sass mixin, is a handy way of grouping multiple CSS values together so you can easily reuse them in several [...]