# Rubbing Noses With inuit.css

Hey there, I’m Harry, the creator of a recently rewritten CSS framework called inuit.css. This article should hopefully serve as a quick intro to what inuit.css is, why it’s different and how you can start using it right away…

## Another CSS Framework is Born

First off, I know what you’re thinking; another CSS framework?! Well, the short answer is yes… The long answer is ‘Yes, but there’s a reason for this one…’

CSS frameworks are currently ten-a-penny with plenty of people releasing their take on the CSS framework on a fairly regular basis. The problem with most of these frameworks is that they’re very opinionated; CSS is a styling language so any CSS framework inherently deals with cosmetics and with look-and-feel. inuit.css, however, doesn’t.

A CSS framework making a lot of design decisions is great if you’re a developer who needs someone or something else to handle the design for you, but what if you’re a designer who needs a hand with CSS? Using a framework would mean you’d have to either put up with someone else’s design decisions and opinions or begin deleting lots and lots of code; or both! Someone else’s design will likely be entirely unsuitable for your project, making it almost completely pointless. This is far from ideal, what we need is a CSS framework that does zero styling; a framework which does a lot of heavy lifting.

inuit.css is a powerful little collection of design-free objects and abstractions which construct the skeleton of any site that you can then then lay your design over the top of. inuit.css works in an OOCSS manner, meaning you can break everything out into structure and skin; inuit.css does the structure and you can apply your own cosmetics over the top!

inuit.css also has a file full of variables that will set up your entire project’s typographical scale; they are totally up to you and will be used in order to build a whole host of components around values of your choosing.

inuit.css sorts out a lot of styling headaches, but it leaves you in total control of the styling itself…

Of course, the main competitor for anyone in the CSS framework market is Twitter’s Bootstrap. Bootstrap is excellent if you need something to handle the design side of things; it’s quick to set up and you can drop all sorts of pre-designed components into a project at will. Perfect for the design-challenged developer who needs to quickly throw a front-end together, but no use to a designer who has their own idea of cosmetics but needs a helping hand with some of the trickier bits of CSS.

If you need design, or a quick-win, off-the-shelf solution, use Boostrap! If you need creative freedom, but a scalable, design-free, extensible and powerful helper, perhaps you might consider inuit.css…

## The Principles of inuit.css

inuit.css is a tiny framework built for websites of all sizes; from simple one-pagers, to gigantic, content-managed behemoths that need to grow and grow.

inuit.css is actually ideally suited to massive websites and large teams, and it is built upon a certain few principles to aid this style of development.

### OOCSS

First and foremost, inuit.css is an OOCSS framework. I am a huge proponent of the OO way of thinking; I write and speak about OOCSS a lot. OOCSS is a fantastic way of approaching larger builds; reusing code base on function, abstracting common/repeated design patterns out, DRYing out code, keeping code efficient and portable. All these ideas are baked into inuit.css at its core, the framework is basically just a library of useful objects and abstractions like the nav abstraction, the media object, the island object and a lot more.

Is is this idea of separating structure and skin that makes inuit.css so well suited to projects where a designer or designers are involved. inuit.css provides design-free, structural design patterns, the design team lay their treatment over the top of it.

The ideas of DRYness, efficiency and abstraction are what lend inuit.css so well to large-scale websites. CSS stays slim, abstractions prove more useful and builds are more efficient; these are things that really help out on larger projects.

### SMACSS

inuit.css is built in a SMACSSesque manner. It’s not as granular or complete (as inuit.css is devoid of modules, and SMACSS doesn’t necessarily deal with abstractions and OOCSS) but it shares some common principles…

The idea of writing CSS in specificity order is something that inuit.css takes very seriously; code that redefines or undoes itself over a project is usually bad news, so architecting CSS in a way that avoids this is paramount, particularly on larger builds. inuit.css’ file structure means that each ruleset only ever adds onto previous ones, it never undoes them.

Firstly, we start with our basic reset/restart; inuit.css resets margins and paddings but also defines some useful cross-browser defaults. This is ground zero, your starting point, the absolute most basic.

Next up, inuit.css imports unclassed elements, these are things like headings (h1h6) which are set to the vertical rhythm you defined in your variables file… These allow you to get going with simple, vanilla HTML elements that are all styled as per your chosen variables.

After that, we add objects and abstractions… These are the things which extend your HTML elements (using classes) and do loads of heavy lifting. These objects and abstractions are all element agnostic, and therefore can be applied to almost anything. This keeps them incredibly portable, reusable and, most importantly, useful!

Once you have started to extend inuit.css to work on your own project, the next things you’d be importing are your components or modules. These are things that are built out of objects and abstractions and their relevant extensions (e.g. turning the media object into a user profile image and bio).

Finally, inuit.css pulls in any helper classes and ‘style trumps’. These are things like width and push/pull classes for your grid system, your brand colour and face as useful classes and even a debug mode for development.

### BEM

BEM is an immensely powerful front-end methodology dreamt up by the developers at Yandex. BEM is, put simply, a way of naming CSS classes to make them more strict, more clear and more powerful. inuit.css uses a BEM methodology with a naming convention based on work by Nicolas Gallagher.

BEM stands for block, element, modifier.

A block is like a component, an element is something that goes toward building a block as a whole, and a modifier is a variation of a block, for example:

Here we have a .comment block which can contain an element called .comment__body. We can also see that there is a variation of .comment called .comment--guest. From the classes alone we can clean what each thing does and what their relationships are to one another; .comment__body must live inside .comment, whilst .comment--guest has to be a variation of .comment.

The __, -- notation tells us a lot about an object. This is particularly useful in larger teams as it helps communicate how, where and when classes should be used.

A good analogy of how BEM works might be:

Here we can see that the basic object we’re describing is a person, and that a different type of person might be a woman. We can also see that people have hands; these are sub-parts of people, and, in turn, there are different variations of these, like left and right.

### Sass

Sass is used for a number of reasons, mainly so that:

• We can split files out meaning you can call in objects and abstractions as and when you need them. This means that your code stays slim, only ever using as much as you need to.
• We can use variables which allows inuit.css to set up an entire typographic scale and vertical rhythm around your own decided values.
• Code is easier to maintain as there is physically less of it in the precompiled source.
• We can minify CSS as we go, which is incredibly important considering how many comments inuit.css contains!

Moving inuit.css onto a pre-processor wasn’t an easy decision, but it’s one I’m glad I made. Combining OOCSS with Sass has proved invaluable, and using variables to set up your custom project means no two inuit.css builds ever look the same.

## Getting Started

Setting up a project on inuit.css couldn’t be simpler. Assuming your project has a very basic structure, like this:

Then your first step is to get inuit.css into that CSS directory. There are two ways you can do this:

1. Delete the CSS directory, cd into the project directory and clone with Git: git clone https://github.com/csswizardry/inuit.css.git css && cd css/ && rm -rf .git/ && cd ../. This basically says ‘clone the inuit.css project into a directory called css, then go into css/ and remove the Git versioning from the inuit.css files, then go back to the project directory’.
2. Download the latest inuit.css zip and unpack it into the CSS directory.

Once you’ve done that, your project should look a little like this:

Firstly, you can completely delete README.md. Next, rename your-project.scss to whatever you wish, for example style.scss.

Note: If you use CodeKit, or some other interface to compile your Sass, jump to the end of the tutorial where we'll take a quick look at setting up an inuit.css project that way.

Now you need to open watch.sh, where you should find something like this:

In here, you need to change every instance of your-project.scss to the name you chose. This little file takes the pain out of watching Sass files from the command line.

Now to begin watching your project files you just need to open a Terminal window, cd to the project’s CSS directory and simply run sh watch.sh. Voila, your project is now set up on inuit.css.

### Variables

As mentioned, inuit.css comes with a bunch of variables that do a whole load of things, if you open _vars.scss you should see them all…

$debug-mode is handy for projects in development; this will invoke the debug plugin that comes with inuit.css and will visually flag, in the browser, any potentially inaccessible or troublesome code. $base-font-size and $base-line-height are fairly self explanatory but incredibly important. Given these two pieces of information alone, inuit.css can begin setting up your entire vertical rhythm (see the font-size() mixin in _mixins.scss for more info). The rest of the variables are pretty much just font sizes for your headings. These, coupled with your $base-font-size and \$base-line-height variables, are what complete your vertical rhythm. Try altering these variables and see what happens!

### One Last Thing…

The next step is one I find very useful; open up inuit.scss and you will find a huge table of contents and a long list of imported partials. It is good practice to comment out all of the objects and abstractions right away and uncomment them as you require them. This means you have to intentionally call them when they are needed and that you aren’t bundling a lot of unused CSS.

With your files being watched, your variables set and your unused objects commented out, you’re all set up on inuit.css…

## Working Without the Command Line

There's a good chance you don't work directly with the command line, in which case you can use one of the many applications available for compiling Sass. CodeKit is one such example and (in terms of what we need it for here) behaves much like any other compiler, on whatever platform you're running.

So then, to set up an inuit.css project, you'll first need to grab the source files from the GitHub repository:

Once you've unzipped the files, organize them into a familiar project layout, like this for example:

As you can see, I've thrown the contents of the inuit source folder into a css folder. I've also gotten rid of the README.md and watch.sh files.

Next, open up your compiler (CodeKit in this case) and instruct it to watch your project folder. In most OS X compilers this is just a case of dragging your project folder into the application window. As you can see below, CodeKit is now watching my inuit.css-master folder and has highlighted the .scss files which will be directly compiled. Any file with a preceding underscore won't generate its own .css file, though it can be imported into other files.

I haven't renamed anything in this case, but you'll see that your-project.scss is set to compile into its .css namesake. All I now need to do is hook that css file up to my index.html:

Any time I save my project files in a code editor, CodeKit recompiles the project for me and reloads the browser window on the fly.

## Extending inuit.css

Extending inuit.css is something we can cover in the second part of this tutorial, but for now all you need to know is that it’s as simple as your-project.scss tells you: