inuit.css v5.0 the Object Oriented CSS Framework

10 June, 2014

inuitcss

Twitter's Bootstrap has understandably become a very popular CSS framework, but if you're needing more creative freedom there's inuit.css. According to inuit.css' README file it's "a powerful little framework designed for serious developers."

inuit.css is an Object Oriented CSS (OOCSS) framework that uses Sass and a BEM-style naming convention. It comes with a powerful library of objects and abstractions that you can opt-in to (so there's little CSS bloat from unwanted objects). Developed by respected CSS guru Harry Roberts, it is relatively light-weight making it ideal for sites of all sizes.

What is Object Orientated CSS (OOCSS)?

This is one of the most important aspects of inuit.css. OOCSS is an approach to writing CSS that aims to produce more maintainable and better performing stylesheets by reducing repetition. It encourages us to look for patterns in designs so that common features can become reusable objects that can be used anywhere.

OOCSS is all about writing DRY (don't repeat yourself) stylesheets and is based on two principles:-

  1. Separate Structure and Skin
  2. Separate Container and Content

Principle 1: "Separate Structure and Skin"

The first principle is about abstracting repeated structural and visual features of a web page (or more importantly the site) into class-based objects. This means that we want to separate layout styling (the structure) from the design styling (the skin) and define these as reusable objects. These objects can then be mixed-and-matched to produce the desired visuals.

To better explain this let's take a look at an example. Imagine we have some markup and CSS like this:-


<div class="content">
    <div class="intro">...</div>
    <div class="promo">...</div>
</div>

[css]
.content {
width: 460px;
float: left;
padding: 20px;
margin-bottom: 20px;
background-color: #fff;
}
.intro {
padding: 20px;
margin-bottom: 20px;
border: 1px solid #ff8;
background-color: #ffc;
color: #333;
}
.promo {
padding: 20px;
margin-bottom: 0;
border: 1px solid #111;
background-color: #333;
color: #fff;
}
[/css]

You should see some repetition in the structural styles that we can abstract out. So we define an 'island' class and rewrite the above as:-


<div class="island content">
    <div class="island intro">...</div>
    <div class="island promo">...</div>
</div>

[css]
.island {
padding: 20px;
margin-bottom: 20px;
}
.island > :last-child {
margin-bottom: 0;
}
.content {
width: 460px;
float: left;
background-color: #fff;
}
.intro {
border: 1px solid #ff8;
background-color: #ffc;
color: #333;
}
.promo {
border: 1px solid #111;
background-color: #333;
color: #fff;
}
[/css]

Now whenever we need a padded content area we can apply the 'island' class.

(The 'island' abstraction comes with inuit.css you will just need to enable it, which we will come on to a bit later.)

Principle 2: "Separate Container and Content"

The basic idea behind the second principle is to avoid using type selectors. So rather than define a selector like .article h2 that targets a specific <h2> we'd create and apply a class that describes the <h2>, for example <h2 class="article-title">. Doing this will mean that:-

  • all unclassed <h2> will look the same
  • all elements with the 'article-title' class will inherit the same styles regardless of whether or not it is a <h2>
  • no need to create an override in the case that we want .article h2 to look like a normal <h2>

Type selectors should be reserved for defining the basics, or in other words resetting the styles. The styling of an unclassed element should not be dependent on where it is placed in the page.

As ID selectors are non-reusable in the sense that an ID must be unique on a page classes are preferred in OOCSS. This is not the same as never use them, but remember that IDs work a little like !important in that they make it harder to override styles; if you find yourself having to write ever increasingly complex selectors to override styles you're most likely defining your CSS rules badly. IDs in markup should ideally be reserved for anchors and JavaScript hooks.

Benefits of OOCSS

One of the benefits of using OOCSS is improved performance. The DRY approach should lead to smaller file sizes and as a result faster downloads. It could also be argued that using fewer descendant selectors should improve the rendering rate of the page in the browser (the descendant selector is the most expensive CSS selector).

OOCSS stylesheets should also be easier to maintain. When adding to an existing site you should be benefiting from being able to reuse many of the objects already created rather than having to constantly append new rules to the bottom of the stylesheet.

The BEM Naming Convention

BEM stands for Block Element Modifier and is a naming convention for CSS classes used by inuit.css.

Blocks are the independent components of a page, things like an article, a comment or a menu. Elements are parts of a block that are dependent on the block that contains them, for example an article title, a comment body or a menu item. A modifier represents a variation of a block from the basic CSS rules such as a featured article, an editor's comment or the primary navigation menu. For example:-

[css]
.article {} /* Block */
.article__title {} /* Element */
.article--featured {} /* Modifier */
[/css]

You'll notice we're using a double underscore (__) and double hyphen (--) notation to distinguish between a block name and its element and modifier names; this means that single underscores and hyphens can continue to be used to separate words in long names without confusing them with the BEM names, for example .menu--primary-nav would be a 'primary-nav' modifier of a 'menu' block.

As an element is named in the context of the block it belongs to we can reduce usage of descendant selectors as we know that the element is contained inside the block through the class name. So rather than define a rule with the selector .article .article__title we just use .article__title.

A much fuller explanation of the BEM methodology can be found on the BEM website.

Sass

If you've not come across Sass yet it is a CSS pre-processor. You can find out more on the official website or the numerous articles out there.

inuit.css utilises Sass for a number of reasons. It allows the code to be split out into different files without impacting on the end number of assets required to be downloaded. OOCSS abstractions are kept in self contained files that can be included on an as-needed-basis so that you can avoid CSS bloat.

Variables are used to power much of the framework and provide a vertical rhythm based on values that are useful to you.

Use of a pre-processor also makes it easy to minify the CSS as you go keeping the file size down to a minimum.

When using Sass to write OOCSS it's important to remember that the same principles apply. A big mistake I've seen people new to CSS pre-processors make is to get over excited by nesting and end up with a mess of deep nested selectors resulting in overly complicated descendent selector rules.

Installing inuit.css

To install inuit.css you can either grab the files by downloading the zipped source code from its Github repository or by using the recommended way via the command line:-

$ git clone --recursive git@github.com:csswizardry/inuit.css-web-template.git your-project-folder
$ cd your-project-folder
$ ./go

This should install an instance of inuit.css with a file structure like:

your-project-folder/
    css/
        inuit.css/
        _vars.scss
        style.scss
        watch
    index.html

The watch file in the css folder is a little helper script for watching for changes to your Sass files and compiling them to CSS. You'll probably want to edit this file so that it saves the CSS to where ever you want it putting. The watch file is there to make things simpler, but you can always just directly run Sass for your project to compile the CSS if you want to; otherwise simple run the watch file from the command line and you should be good to go:-

$ ./css/watch

Using inuit.css

You should now have a working copy of inuit.css and can get started building your project.

There are two files that you'll want to work with: _vars.scss and style.scss in the css folder. _vars.scss is for defining your project variables and enabling inuit.css abstractions and styles.scss is for extending the framework and defining your own rules.

The library should all be contained within the css/inuit.css folder. The code in this folder shouldn't be touched, if you want to override something this can be done by either:-

  • setting a variable in _vars.scss
  • defining a new rule in styles.scss

The default variables used by inuit.css are all defined in _defaults.scss. The $base-font-size and $base-line-height variables are probably the most important two as they will define your vertical rhythm. These are shipped as 16px for the base font size with a line-height of 24px (1.5). So if you wanted to reduce the font size to 14px you would add the following to your _vars.scss file:-

[css]
$base-font-size: 14px;
$base-line-height: 21px;
[/css]

Then whenether you need to set a font size in one of your own rules you can use inuit.css' font-size mixin to maintain the vertical rhythm:-

[css]
@include font-size(10px);
[/css]

Using the font-size mixin converts font sizes into rem units (with a fallback for older browsers) that makes dealing with font sizes on a responsive site easy.

The bulk of the framework's code is split between three folders in css/inuit.css:-

  • generic - the basics like CSS reset and normalizing, helper classes and Sass mixins
  • base - design agnostic styles and modifiers for HTML elements like headings, forms and tables
  • objects - OOCSS abstractions that need enabling in _vars.scss

As previously mentioned inuit.css' objects are disabled by default to avoid CSS bloat. You will need to enable them as and when you need them from within _vars.scss. For example to enable the island abstraction discussed earlier you just need to change the $use-island variable to true:-

[css]
$use-island: true;
[/css]

styles.scss should be used for extending the framework and adding in your own project specific style rules, but it's worth splitting these down into smaller files to aid maintenance. inuit.css suggests putting these in a 'ui' folder and importing these into your styles.scss file, but really the choice is yours. inuit.css is a very flexible framework. It's always worth keeping your own abstractions and Sass mixins in separate files as this will make them easier for reuse on other projects.

Final Words

Not everyone is a fan of the OOCSS approach, but it is based on sound advice of avoiding repetition and CSS bloat. When used right it can really help reduce file sizes leading to improved site performance due to smaller download sizes. I've seen this approach really aid larger projects that could have otherwise become a nightmare to maintain.

inuit.css' light-weight and creative freedoms make it a good choice when styling up a site that has been lovingly designed by your webdesigner.

On the downside there is no official documentation online (for now), but the code is extremely well commented. Just open up the inuit.css folder and take a look at the code, much of it includes useful examples linked to jsfiddles so that you can see the code in action. An unofficial inuit.css Kitchen Sink site has been put together that has pulled all these comments and examples together into a handy page showing what the framework can do that is worth a look.

Written by Andy

With more than two decades’ coding experience under his belt, Senior Developer Andy continues to prove an integral part of the Evoluted development team. Having been with Evoluted since 2012, he has worked on countless projects for our clients. An analytical thinker, his background includes time spent working as a theoretical physicist; which involved research into Quantum Optics.

Up next…
5 tips for creating an effective mobile website
6 June, 2014

0 Comments

No comments just yet!

Leave a comment

Replying to: - Cancel