I have been sitting on the first part of this blog post almost for the past 5 months since I first used Susy "framework". Recently when this Smashing magazine post beat me to it, I almost thought rather not bother writing another "been there done that" post but I suppose this could be sort of a TL;DR version while also covering some quick basics, hopefully in a more overview angle.
I've made this into a two-fer including yet another reason to "Grunt" as there seemed to be a segway for that. Even if you have been using Grunt, stick around for this cool grunt task find.
Why a semantic grid?
You wouldn't probably be reading this post if you didn't feel the need for semantic frameworks... We all know the pains of frameworks in general, dependencies of framework files; mark-up littered with presentational classes (small-12, medium-6, large-3 and what have you) although some frameworks have mixins to prevent those; version updates; bloat to some extent if not used responsibly, although not much compared to all those tons of crazy un-optimized images on your page (can't help bringing that up).To clarify, Susy isn't the only framework to use this semantic approach, just the one that I've used... I hear the latest version of Foundation, 6.0 (not yet released as of this writing) is also one that's going towards that.
A few key things you need to know about Susy:
It isn't really a framework per se as in, a file/s (grids and more) that you physically include in your <head> as in Bootstrap or Foundation etc. So it doesn't add any additional files/size to your Sass, or compiled CSS files!!Although you can install it as a Ruby gem, I want to really stress that it can be used stand-alone without any Ruby dependencies. Just include the Susy folder in your project folder as below!
You can use it with Compass if you are already using it, but, not a dependency.
You do need to be using Sass though. Sorry, "Less"er folks... another reason to switch to Sass :-b Some Sass compilers didn't work at the time of my use (threw some errors), and the one that worked for me is the Koala compiler.
But, more importantly, although Sass is used while in the pre-processor stage, it isn't really a dependency in the final output. Once CSS is compiled, all the widths, columns and gutters are converted into straight percentages and can be ported into any environment as just straight CSS without the need for any framework files.
So then, you may ask, why not just use plain percentages manually to begin with? Frankly for the kind of complex responsive layouts we use these days, I'd rather keep my code "DRY" and not have to calculate percentages, gutters, margins, suppressing margins for the last-child, first-child and so on for every other div or complex product grids, with different configurations in each media-query etc., but rather focus on layout and quick delivery (set it and move on!).
So how does Susy does the "magic" of sizing your columns, with gutters, margins, margin suppression etc. The pics below are self-explanatory.
You set all your grid variables like below in the settings file (which you will be importing to your Sass files...
You will be using it in your Sass file like below although not the best complex use-case scenario (btw, the breakpoints below are just basic Sass mixins I used. Nothing special referring to Susy, but the @include span is).
And you will get the compiled CSS output like below... Ta Da!
One more (rather two more) reason/s to use Grunt
Although it isn't quite possible to port Susy to Less in a completely automated way, there is a Grunt task for converting Sass to Less in general! Better to just convince others to use Sass, I guess.
Here's a cool Grunt task for Sass > Less that someone has cared to share on Github.
In general if you just want to "cleanify" your pre-processor compiled CSS, eg. when porting/delivering it to another environment, perhaps as a front-end deliverable, here's the Grunt task to "cleanify" pre-processor output.
I've also wondered if all that ugly pre-processor CSS output with ungrouped media-queries for each element would cause performance issues, but I read this post testing that hypothesis which assured they didn't find significant performance issues with the pre-processor CSS output. Nevertheless it is still good to clean up . Kidding aside, these tasks can be really useful in real-world situations.
To clarify, I didn't write the above grunt-tasks but just recognizing and linking to someone else's good work. I have personally used the second one and I love the output! Not sure how you would accomplish things like above (and lots more) without Grunt.
If you can think of some grunt-work, there's perhaps a Grunt task for that and someone has already shared it for the world to use. Good to use it and spend the time on something more challenging or less "grunty (or the interns could work on something more interesting ;)) If you still aren't convinced to use Grunt, read the famous Chris Coyier's post on using Grunt.
A few notes from when I was trying to install Node and Grunt below. These may seem simple enough but will save you a lot of time wondering why your grunt task isn't running or some other snafu.
- You need to first install Node JS (lots of details in the above post).
- If Node JS install isn't working, install with sudo command.
- You MUST HAVE the package.json (which will have your dependencies and your Grunt tasks) in your project root directory and the Gruntfile.js (which will have your grunt tasks).
- You will be installing packages via npm (node package manager) and they all get downloaded into separate folders, but I found it way simpler to just put the necessary grunt tasks js files right into just the "tasks" folder off of your project root and just referencing directly in your Gruntfile.js (if you have it elsewhere, make sure you configure your paths right).
Hope this will be helpful to some. In general they serve as my own reference for later :)
