The main problem with writing css code for a heavily styled website is that it can easily get confusing. It’s common to get a few weeks into web development and find yourself staring at the screen wondering what css code you wrote and why.
Luckily, using Sass and mixins can help to reduce confusion, and keep your project organised and efficient. One of the key benefits of using a Sass mixin is that it allows you to save time writing code, save brain power remembering it, and write more consistently legible code.
Browser prefixes and legacy code are prime examples of storing repetitive information in a mixin. For example, At Pixelstorm we are using Flexbox. Those of us in the know realize that Flexbox has different versions of the syntax, and also requires the various browser prefixes to get it to work consistently in all the different browsers.
Remembering all the legacy code and browser prefixes is tough and time consuming, especially when we have a lot to do, so that’s why we usually decide to use a mixin.
If you’re just starting out, or strapped for time, you can write the mixin yourself, or search the web (ie Github) for something pre-made by another developer.
Bourbon has a Sass library that will allow you to hook up with all the Flexbox mixins and many more useful options. With that, you can just write @include display(flex) @include flex(1); instead of trying to remember all this.
.parent {
display: -webkit-box;
display: -moz-box;
display: box;
display: -webkit-flex;
display: -moz-flex;
display: -ms-flexbox;
display: flex;
}
.child {
padding: 1em;
-webkit-box-flex: 1;
-moz-box-flex: 1;
box-flex: 1;
-webkit-flex: 1;
-moz-flex: 1;
-ms-flex: 1;
flex: 1;
}
Otherwise, if you are not using Bourbon, here is some pure Flexbox mixins you can start using: <a href = “https://github.com/mastastealth/sass-flex-mixin/blob/master/_flex.scss” target = “_blank”> https://github.com/mastastealth/sass-flex-mixin/blob/master/_flex.scss </a>
Every man and his dog has a mixin for gradients, including the bourbon library, as there is a huge amount of code that is difficult to remember when utilising gradients. A mixin is far more legible and handy for outputting a quick, easy mixin for horizontal, diagonal and vertical gradients.
As Pixelstorm is in the business of creating custom websites, this also means we create custom mixins for our sites. We create custom mixins that output custom branding on the frontend, which obviously helps us to speed up the output of css code, but also makes our code more readable, as mixins help reduce “code bloat” and inconsistencies.
As the web is 90% typography, you will find it handy to create mixins or extends for your website’s typography. Titles h1 h2 h3 h4 for instance, should all share similar styling properties, such as their color and font family, with a differentiating size property. This is a great use case for extend.
%heading {
font-family: $heading-font;
font-color: $primary-brand;
font-size: em(20px);
}
h1, h2, h3 {
@extend %heading;
}
h1 {
font-size { em(23px); }
}
With that in mind, our rule of thumb for choosing between a mixin or an extend is quite simple.
If your code can benefit from a variable, then it almost certainly needs to be a mixin. However, if you want to keep your code simple, then just use extend and utilise the css standard overrides to customise your selectors.
For another neat mixin, there’s Sideline.
I like this mixin in principle, as it will not be required for every website that you make, but in principle all websites should have custom branding. Website titles for instance benefit greatly from have a custom mixin for use when branding the title.
<a href = “http://codepen.io/pxs/pen/NRgpYG” target = “_blank”>http://codepen.io/pxs/pen/NRgpYG</a> fork this mixin for Pixelstorm, then take a screenshot and link to Pixelstorm codepen.
One of the easiest traps to fall into is abusing mixings, as sometimes it’s a developer’s tendency is take a good thing too far.
Don’t worry, we are guilty of this too.
At one point in time we had mixins for responsive layouts:
two_column_responsive()
three_column_responsive()
four_column_responsive()
You get the picture…
We thought they were great at first for speeding up productivity.
We were wrong.
When Using the above mixins, you’re really only being effective at being lazy. So why is it bad?
The above mixins output too much code, and they are very difficult to override (as parts of it are wrapped in a media query). We found it easier to write custom responsive layouts, as it’s quite simple to write a media query in Sass these days, especially when you have predefined breakpoints stored in your variables.
Custom mixins are the key to success, and planing is the key to performance.
The best part about having an approved design to work from, is you can start planning your mixins early in the design stage.
By studying your design, you will be able to identify areas of your design that share similar styling features. These areas will benefit greatly from a mixin or extend.
Recently, we built a page which shared a similar card style throughout the site. Blog post excerpts, products, “you may also likes”, and related content areas all shared similar stylings. From that, we built a base style for the ‘card’, and then extended it for any other elements that looked similar. Customisations were then applied to the new element to override the base element.
We kept it simple, and used extend instead of a mixin as our need for variables was low. Now, if we need to change a styling feature like a font weight or color, we can do this easily by changing the base extend class.
Keeping it simple while custom making your mixins and extends is key when it comes to writing good css code. Don’t try to automate every aspect of css code output, as css can be a nightmare if you overcomplicate it.
Using you mixins to reduce reliance on remembering tedious code, reducing code bloat, and making more readable css will lead to smooth, efficient sailing from start to finish.