7. Use mixins sparingly (and avoid @extend)

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.

Tip

Font stacks are difficult to get right and tedious to author. The sanest way I've found to deal with fonts is to have the body use the most common font stack and then only override this with a different font-stack as and when needed.

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.

Avoid @extends

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 references

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 @includes

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?

Using @extend

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
52.15.74.25