Avoid the temptation of abstracting code into mixins. There are a few areas where mixins are perfect. The code for CSS text truncation (e.g. @mixin Truncate
) or iOS style inertia scrolling panels, where there are number of pseudo selectors to get right for different browsers. Another good use case can be complex font stacks.
For example:
.med-Video { position: relative; background-color: $color-black; font-size: $text13; line-height: $text15; /* At medium sizes we want to bump the text up */ @media (min-width: $M) { @mixin FontHeadline; font-size: $text15; line-height: $text18; } }
For simpler font-stacks, a variable can handle this need easily so may be preferable. However, mixins are great for more complex font stacks, where it's preferable to have certain font stacks apply in certain situations. For example, perhaps one font is required for LoDPI, and another for HiDPI. These situations can't be dealt with by using a variable alone so a mixin is used as needed.
Ultimately, aim for ten or less mixins in a project. Any more than that and it's probable mixins are being abused to needlessly abstract code.
I first came across @extend
when using Sass (http://sass-lang.com/documentation/file.SASS_REFERENCE.html#extend). The @extend
directive makes one selector inherit the styles of another selector. While this can offer some file size benefits it can make debugging more difficult as rules are combined together in a manner that is not always possible to predict at the point of authoring.
To determine whether using @extend
was worthwhile I did a short experiment on a Sass codebase I was working with at the time. There were 73 instances that would require a Headline font stack and 37 instances that would require a headline condensed font stack (so if going the mixin route, that's 73 @include Headline
and 37 instances of @include HeadlineCondensed
).
Let's look at what the file size was with no font references at all, the font references defined as mixins/@includes and then the font references as @extends
With no font declarations at all:
105.5 KB (minified), 14.2 KB (Gzipped)
This is our base or control if you will. Let's look at the difference adding all our fonts in via mixins/@includes creates.
Using mixins (@includes in Sass) for the Headline and Headline Condensed the file size of the resultant CSS was:
146.9 KB (minified), 15.4 KB (Gzipped)
So, 1.2 KB added. How does @extend
fare?
By using an @extend
rather than an @include
:
106.9 KB (minified), 14.5 (Gzipped); only a .3 KB file size increase.
What to conclude from this anecdotal data? For me, all other things being equal, if you absolutely want the smallest file size, perhaps @extend
is the way to go. There is some saving, albeit minor.
However, being pragmatic, if there is any maintainability gain for you using @include
instead of @extend
I certainly wouldn't worry about the file size.
Personally, I don't allow @extend
functionality in projects. It adds an additional layer of complexity to debugging for very little benefit.
52.15.74.25