Front-end Process - Flat Builds and Automation, Part 4: CSS Framework

Posted by Matt Bailey on 12 June 2013

In part one we discussed what a flat build is and why to use it. In part two I outlined how to set up your dev environment, and how to scaffold a project using Yeoman. In part three we looked at how to install and configure some grunt tasks. In this fourth and final part of the series I will go through adding and starting to structure a CSS framework.

Step 1 - Install CSS framework

These days many developers use a CSS framework as the ’backbone‘ of their projects. A framework could be something very fully-featured, such as Bootstrap, or a simple, un-opinionated code base such as inuit.css. A good framework should help speed up your development, provide cross-browser functionality, and encourage good coding habits. Some developers argue that frameworks are restrictive and add a lot of ’overhead‘ to a project, but I would argue that, if used correctly', the benefits outweigh the negatives.

What you choose to use depends on your requirements, but I have settled on inuit.css. It comprises of a collection of objects and abstractions (object oriented) and, as I said above, is very un-opinionated. What I mean by that is that it contains little-to-no design, just design patterns. The core principles of inuit.css are scalability and reuse.

First of all you need to install inuit.css as a component. Although the inuit.css core is available as a package through Bower it’s actually the inuit.css web template I recommend you use as it does some of the initial scaffolding for you.

In your terminal navigate to the components folder: 'app/components/'.

Once in the 'components' folder run the following command to clone the inuit.css web template:

git clone --recursive git@github.com:csswizardry/inuit.css-web-template.git inuit.css

Then, navigate into the 'inuit.css' folder and run './go' to complete the set up.

Your inuit.css folder should look like this:

app/
|
`-- components/
    `-- inuit.css/
        |-- css/
        |   |-- inuit.css/
        |   |   `-- …
        |   |-- _vars.scss
        |   |-- style.scss
        |   `-- watch
        |-- .gitmodules
        |-- index.html
        `-- README.md

You now have the inuit.css framework at your disposal. The most important thing to remember from now on is that once you have installed it as a component you should never edit the contents of this folder directly. This means that should you wish to update inuit.css in the future it’s a simple matter of replacing this folder with the newer version (in fact this applies to everything in the components folder).

So how does one go about using inuit.css if you can’t edit the contents of the folder? Well here’s how...

Step 2 - Using inuit.css

First of all we need to prepare our 'styles' folder to make it easier to organise things. Inside of 'styles' create three new folders; 'modules', 'partials' and 'vendor'.

|-- app/
`-- styles/
    |-- modules/
    |-- partials/
    |-- vendor/
    `-- main.scss
  • The 'modules' directory is reserved for Sass code that doesn’t cause Sass to actually output CSS. Things like mixin declarations, functions, and variables.
  • The 'partials' directory is where most of the CSS is constructed, broken down into modular, reusable code, eg. typography, buttons, textboxes, select lists, etc. (SMACSS or OOCSS).
  • The 'vendor' directory is for third-party CSS.

Go back into the 'app/components/inuit.css/css/' folder and open '_vars.scss'. Save a copy of this file into the 'modules' folder you just created.

Open 'main.scss' and remove all of the content. From now on you shouldn’t put any regular css in this file, only imports of other files. On the first line of the file it’s good practice to define the character set of the file:

@charset "UTF-8";

Then after that add the following imports:

@import "modules/vars";
@import "../components/inuit.css/css/inuit.css/inuit";

These two lines will import the '_vars.scss' file you just created and the inuit.css framework.

In '_vars.scss' you will find options to enable/disable features. Initially they will all be disabled. You should only enable the features you want to use - this will keep your code nice and lean. For example, if you wanted to use the grid system you would set the 'use-grids' value to 'true':

$use-grids: true;
$use-flexbox: false;
$use-columns: false;
...

To find out more about inuit.css and how to start using it in your projects you should read the documentation on github. If you want to see it in action there is a dedicated jsfiddle account containing lots of examples. The source code is also very well commented.

So, following the inuit.css philosophy you should start creating modular css files - 'main.scss' might start looking a bit like this:

@charset "UTF-8";
/**
 * main.scss
 *
 * Never add styles directly to this file - set up imports
 */


/* ==========================================================================
   Imports
   ========================================================================== */

/* Setup inuit.css
   ========================================================================== */

@import "modules/vars";
@import "../components/inuit.css/css/inuit.css/inuit";


/* Compass
   ========================================================================== */

@import "compass/css3/transition";
@import "compass/css3/opacity";


/* Modules
   ========================================================================== */

@import "modules/mixins";


/* Partials
   ========================================================================== */

// Base css
@import "partials/typography";

// Page structure
@import "partials/scaffolding";
@import "partials/header";
@import "partials/footer";
@import "partials/nav";

// Misc
@import "partials/ie"; // IE specific css
@import "partials/shame"; // Stylesheet reserved for temporary hacky code


/* Vendor css
   ========================================================================== */

@import "vendor/jquery.ui.core";

For help writing beautiful CSS I would highly recommend reading this document by Nicolas Gallagher: Principles of writing consistent, idiomatic CSS. I use this as a style guide for all my CSS documents.

For more advice on structuring your SASS projects (and from which I‘ve based most of my own project structure) I recommend the following articles:

So there you have it - the basics of a front-end, automated flat build process. I hope you’ve found this series of articles helpful and if you decide to take the plunge, good luck!

Notes:

  • inuit.css is a Sass based, Object Oriented CSS framework.

A note on why we are using SASS rather than Less

Up until now we have used Less as a CSS preprocessor. First of all let me just say that there’s absolutely nothing wrong with Less and we will probably still use it on some of our projects - Boostrap uses Less (although there is a SASS port that is well maintained and used by Yeoman’s yo webapp generator) and we have a few projects based on Bootstrap. For those of you who like Bootstrap, but only want the mixins and variables and none of the ‘extras’, there is also the excellent PreBoot. But in general we believe SASS is the way forward for us.

One big selling point is that if you use SASS you can also use Compass, a fantastic CSS authoring framework containing reusable patterns, mixins and other tools. It also has actual logical and looping operators, and it has the @extend function and placeholders to name a few other benefits. The good thing about Compass is that it's also modular, so you only need to include the things you actually need. If you refer back to my example 'main.scss' file above you can see that I've included the Compass mixins for CSS3 cross-browser 'transition' and 'opacity'.

Also, and this is a more personal thing, most of the front-end people I ‘follow’ use SASS, so I hear more about current SASS techniques and methods than I do for Less.

Article Index


You can follow Matt on Twitter, Dribbble and Google Plus.

Comments (5)

  • Stefano F. Rausch Stefano F. Rausch on June 14th, 2013

    Interesting setup.

    On a Mac OS box an alternative, without all the installation hassle, could be the use of either CodeKit or Hammer – most probably suitable for 1 - small teams only, due to licensing?

    With Hammer you can even "package" project templates to be distributed accordingly.

    Just food for thought.

  • jonschlinkert jonschlinkert on June 14th, 2013

    Nice article, Matt! You did a great job articulating some of the reasons we created assemble. IMO now that there are so many frameworks and UI toolkits at our disposal the "next big challenge" is developer workflows, getting (and staying) on the same page as our team mates, and using these tools effectively and idiomatically. I'm glad to hear that assemble has made at least a part of your development process easier!

  • Ian P Ian P on June 17th, 2013

    Thanks for this post. I find it interesting how you use elements of inuit.css and Compass as well. I've used both projects (seperately!) - do you see any overhead or problems when you use both together like this?

  • Eddi Chen Eddi Chen on June 20th, 2013

    Great article! It's nice when someone posts about their experiences in using these new tools. Do you think there could be an issue with reliance on third-party tools automating processes so much that people may lose sight of what it's actually doing?

  • Matt Matt on June 25th, 2013

    @Stefano - CodeKit (which we already use) and Hammer are fantastic tools for sure, and they definitely make things easier for people than all this command line stuff ;) However, I'm one of those people though who enjoys finding out how things work and pushing myself to learn new things. I set myself a challenge to implement this workflow, and it's been a huge amount of fun doing it.

    @jonschlinkert - Exactly (and I think this is what @Stefano was alluding to as well), the challenge is to push out this kind of workflow so that it works in a team context. It's something we're working on as it does require a lot more communication and collaboration between the 'front-end' and 'back-end' guys, but I just see that as another brilliant challenge to have.

    @Ian P - I don't really see any overhead issues using inuit and compass together. They're both completely modular, so you only use (and therefor compile) the bits you need. At the moment I'm using inuit for all of the 'core' stuff and compass as a complimentary 'framework' for some of its mixins.

    @Eddi Chen - Thanks Eddi. We've spoken before about front-end workflow and I know we're on the same wavelength. Yes, there might be a danger that we get so caught up in how 'cool' these tools are that we get carried away and forget what they're actually for. But equally I think we need a period of experimentation and learning to be able to find out the best way to use them. This kind of process is fairly new, and those who are investing time in it are still finding their feet. But, that's what's so exciting about it!

Post your comment