/Reviewing InuitCSS

Code.

Love it or hate it, the CSS framework is here to stay. I for one lean towards the "It's a must" camp of the debate, so I guess if I start the debate up again on this site it would be biased from the word go. So let's not. Let's rather talk about the latest Framework to hit the 'nets - Inuit CSS.

InuitCSS is a very new, actively developed (sometimes to the point of some frustration) and above all - very light CSS framework. It provides the by now default CSS reset, grid (based on the 960.gs) system, type setup, table setup... you know, everything that we have come to expect from a CSS Framework.

That is also where the similarities end (currently at least). InuitCSS is very light, lighter than any of the other frameworks I have tested out. Since the entire web industry can't stop talking about responsive design practices (really, it's the new web 2.0), it was good to see that InuitCSS has it built in. And it works really well too. Even without ANY tweaking of your design it does the job passably, although a bit messy sometimes.

Unlike blueprint and 52 Framework, Inuit has just a single 25kb css file that you need to include to get the framework goodness. It does ship with a surprisingly handy style.css file that contains a responsive template (no styling, just the skeleton stuff), which if nothing else prompts you to spend some extra dev time to fiddle with it and try to make your site look good on all screen sizes (which is NEVER a bad thing). As of writing Harry Roberts released version 2 of the framework, adding igloos (modules, add-ons, extra loose css files you can add to your site if you want to).

The major thing here is that Inuit makes very little design choices for you. It's marketed as making zero choices for you, but I don't think it's quite there yet. Give it time though, I am sure it will become somewhat leaner in future.

As of version 2.1 Harry fixed one big complaint for me, which firstly makes me feel all awesome and what not, but secondly also makes it a lot more flexible in my opinion. I secretly think he disagrees with me, and probably only did it because I just wouldn't shut up about it!

Update: I believe it's now heading to version 2.5 already!

The Good

Above I have mainly been talking about the stuff I like already, but let's just go ahead and summarise the important bits!

• Harry Roberts is a stand up guy - He is open to discuss his framework with you. If you have suggestions, he will think about it. He replies to tweets and you get a feeling that he nurtures his framework and is really into making it awesome. It's clearly not just another project, but something he really cares about. This to me speaks volumes.
• It's really lightweight, and simple, and straightforward - The inner workings have some weird css I haven't come across yet, but as a whole it just sort of magically works. It's a one file inclusion and wham bam thank you so very much mam.
• It sorts out the heavy lifting in your responsive layout, leaving you to tinker and tweak it all into place. Nice feature.
• It's stable - Cross browser support for the important bits like layout is 100% so far.
• Most importantly - It's pretty see-through. It leaves the design decisions up to you, the designer. That is important.

The Less Good

As with most things, this framework isn't perfect. Let's keep in mind that this is still a very new framework, and that things are bound to change, develop further and settle down. Also note that a lot, if not all of my concerns are personal likes / dislikes and based on what I personally think a framework should be and how it should be used. I know the title of the section sounds very negative, but it really isn't implied to be.

Rapid Version Growth

Nobody enjoys working with stale projects, and everyone wants their favourite project to grow and grow and eventually to take over the world. The converse is also true, it becomes a little bit frustrating when you are working on a project and the framework you are using goes through 3 or 5 version updates. And then a version 2 just as your site goes live.

Look, this isn't a biggie. We understand it's new, and we love the fact that Harry nurtures his framework, and makes it grow. It really will settle down soon I'm sure. This is less of a negative BAD thing than it is a "be mindful of this when adding this to your process or live site" thing. Just know that you will have to do some maintenance for a while.

Code that don't belong

My opinion of a framework is that it should not interfere with your design work and content. A framework that you download from the internet should be relegated to the background, to do the heavy lifting for you, not tell you how things should be displayed or not, which fonts you should use etc. For the majority InuitCSS is really good at this. It is mostly plug in and go about your business. Mostly. There are one or two niggles that I have found, while being good snippets of css, and definitely worthy of attention, should rather be moved into an igloo or something.

Some quick examples I found include:

label:after{
content:":";
}
label::after{
content:":";
}

For me this just doesn't belong in a framework. What if the CMS I am using already adds the ":" (Which actually happened in my case!). I also don't think it's good practise to tell people that you HAVE to use that kind of punctuation after your labels. Usability issues aside, sometimes it's just not relevant. Let's stick to either adding this in html, or if you want it in your css - to your own style.css file.

/*------------------------------------*\
LOGO
\*------------------------------------*/
/*
Your logo is an image, not a h1: http://csswizardry.com/2010/10/your-logo-is-an-image-not-a-h1/
*/
#logo,
#logoimg{
display:block;
width:auto;/* Width of your logo in pixels (ideally a round grid-number) */
height:auto;/* Height of your logo in pixels */
}
/* Based on the fact that we need to use an <img /> in our markup, let's hide the actual image and use a background on the <a>--this gives us sematically sound markup and the ability to use sprites for hover effects! */
#logo{
background:url(/path/to/logo);
}
#logo:hover{
/* Hover states */
background-position:0-00px;
}
#logoimg{
position:absolute;
left:-99999px;
}

I get that he is trying to make a point here, a good one at that. But, within a framework? Is it really the place?

I found that the #nav code he put in was fine in a way, but then below it he added a way to center it, which used an entirely different technique altogether (a technique I find to be much better than his #nav version, whether you are centering it or not). I know that both techniques are good, but why have both? Or, if you have both, why only have the centered version of the one? Why not left aligned, centered and right aligned?

Look, these are all good things to have, and use. But, as I will say more below, it should be added into your own personal framework that you build around Inuit. Inuit shouldn't become the framework that tries to include everything, because then it would just end up like all the rest - bloated. I don't want to have to go override things in a framework. I shouldn't have to touch it all. These inclusions don't do that.

Type Choices that don't belong

Again, all of the CSS Frameworks I have ever worked with did weird things with type, all of them a personal decision (because I like that font) from the developers of the framework. In the Inuit framework it's not actually that bad, but it still puts out fonts that are not available on all platforms as standard. Look i get it, I really do. Fonts are the new in thing, and it's easy to do etc, and look better than the default stacks out there, but remember the point of your framework - It's a framework. It's the base of things to come. A foundation on which to build. You don't want holes like this in your foundation! Let's stick to the defaults.

In Theory

Who should use a CSS framework? Defenitely not the beginner. This framework will certainly allow the beginner to produce some good work, but at the cost of actually knowing what it all does. No, in my mind the frameworks are best suited to the more advanced web dude. The guy who already knows it all, but just can't afford to rewrite it all every single project.

Actually, my feelings toward the frameworks like Inuit is that it should be a good base, on which you build your own framework, suited to your personal needs. It will include all the little bits and bobs that you use everyday in your projects. This is especially true if you work on big sites full-time. We are doing exactly that, building a much larger framework, with inuit at it's core, including our little preferences, much like Harry did with the #logo stuff above.

Actually everyone should have his or her own framework or skeleton files. It just makes your life so much simpler.

Finally

InuitCSS is the second framework that I adopted into my process and way of doing work. I used to love blueprint, but this is just so much better and simpler. More importantly, it got me to actually participate, give suggestions and write about it.

For such a new and fresh framework, to be so brilliant already, I can't wait for what's to come!

• Go get it at: www.inuitcss.com and sommer follow them @inuitcss
• Go check out Harry at www.csswizardry.com/ and give the man a follow @csswizardry