Why they’re worth using – and building

What I mean by a “framework”

What exactly makes a framework a framework? What’s the difference between a style library, a framework and a general CSS library? Lots of different names and terms are put about. For me, a “CSS library” covers all as a more generic term. A “style guide” or a “design framework” is more like a bootstrap with a UI layer on top and more specific stylings. A “framework” is something in the background giving your project that robustness and foundation. This is where Inuit and similar libraries come in.

Why you need a framework

If, like me, you’re constantly moving from one project to the next, you need tools in place to get started quickly. The last thing you want is to have to start at the beginning every time, writing out the simple classes you need for grids, etc. – or even just resetting the CSS. Most people have a tendency to copy and paste from one project to another. At best this can be messy, and at worst dangerous. If you do this, I assume you spend a lot of time later deleting or overwriting stuff that didn’t need importing. A framework gives you a solid foundation to build from. And you can easily customise for each use, choosing just those areas you need.

Give your projects structure

All too often in projects, as the time goes on and the pressure to deliver is applied, we find ourselves faced with the idea of quick fixes. This can be seen by the many projects we come across where developers in a rush have placed CSS at the bottom of a file to overwrite something on top, applying random classes – always with the notion of coming back on a rainy day and neaten it all up.

Having a good foundation gives you the ability to just add that extra class to an element that’s already defined and has the styling you need. You can also move into a workflow where there are separate style sheets for the new objects. You may even wish to create a naming practice for your classes and apply throughout.

Make it your own

Your base framework may not be built by you; but that doesn’t mean you can’t extend it for your own personal needs. There is always a point where you have to create the same objects over and over again for each project. So why not change the framework to use those objects? Or, furthermore, extend so that you can turn those objects on and off depending whether they’re relevant to that project? Even if you start with the best framework in the world, you’ll want to make it your own. The possibilities are endless.

Inuit – An OOCSS framework

Recently our framework of choice has been inuit.css by csswizardry. (You can find Inuit on github here.) Inuit is a great choice for a framework and a solid foundation to build from. Below I’ll go through a few great features of Inuit. (Most, but not all, shared by other great frameworks.) I thought it’d be best to show you how some of the features of this library have benefited us.

Use more classes and less CSS

The immediate difference between Inuit.css and other libraries out there is its use of classes. Inuit’s classes are based on BEM methodology. This can, for your average developer like myself, take some time to get your mind around. If you are really intrigued by this point I advise you to read this great post by Nicolas Gallagher.

There are a great deal of libraries out there that have vast areas of mixins for font sizes and animations. But these generally all use things like Sass @extend to pull that into your classes. The real key with Inuit is that everything is pre-built in to object-oriented classes. Bootstrap also uses classes, but Inuit’s are not styled. With Inuit you can build out most of the structure of your project without writing one line of custom code.

Start with a good responsive grid system

When starting a build, most of us will start with a HTML structure. And we’ll want to get this right first time. Having to constantly restructure is a nightmare – especially after you’ve applied CSS to that structure. Inuit, like other great libraries out there, has built in a grid system, allowing us to quickly structure out our HTML. But Inuit doesn’t stop there; it also has built-in responsive breakpoints. This means we can target break points easily and quickly.

Often we find that with responsive sites as soon as you reduce the viewport size the layout and structure will change. So, to counteract this effect, Inuit has the idea of taking the foundation grid system and names spacing it with its media queries.

To explain what I mean, imagine you have a grid with three columns. On a desktop this looks great. But then you get down to tablet size and you want two columns wide and the third column to be full-width underneath. Easy: turn on responsive grid system. Now you can apply the “one-third” class and next to it place “portable–one-half” class. When you resize down to tablet all of a sudden the “portable–one-half” will overwrite the “one-third” class. Then you can structure your HTML document for all viewports and once again you have not written one line of Sass!

Having the ability to target breakpoints with classes and quickly structure in all breakpoints decreases development time massively. You can see your app come together fast, and build for all devices at once.

Have a custom UI layer

Inuit does not have a design layer. I personally hate the idea that nearly all Bootstrap sites look the same; having a design layer can easily make you lazy and stop you putting that personal brand on what you’re building. Like Bootstrap, Inuit has all those custom objects built in (like buttons and beautons) but with no design on top. Having no design layer allows you to put your client’s custom branding over the top. I can quickly build out custom styles in object-oriented classes and apply them to my elements.

Use Sass

CSS extension languages like Sass give us the ability to do so much more with our CSS. They speed up development and give us the features we need to keep clean, maintainable code in our framework.

Variables may seem like simple things, but do not underestimate that ability to get you off the ground fast. With most projects you start with a design; that design will contain font sizes, colours and a whole array of set things throughout. Wouldn’t it be great if when you loaded that framework into your project you could go and update a “variables” files? In this file you could quickly lay out all those things.

Resetting the CSS

Most developers start their projects with a base layer of CSS. This CSS will most probably be a reset. To get all browsers more or less on the same wavelength, Inuit has normalize built in. Generally, reset libraries do very dissimilar things. Having a CSS-reset is a great idea and can quickly stop you hitting those simple and common cross-browser issues. There’s no need to stick with normalize; you can change it for any CSS-reset. (Or maybe just put in your own.)

The downside?

I know what you’re thinking: “Here we go, you’ve built us up to disappoint us.”

Not really! The only foreseeable downside with a framework is its size. But there are ways around this. Bootstrap’s approach is to let you download a custom build of their library with only the things you need.

Inuit’s approach (something that you should definitely build in if you extend a framework) is to have a place where you turn those objects and features on or off as required. This gives you the easy ability to go “Oh no, I forgot this!” and just turn it on later. None of the code you’ve chosen to turn off will be compiled and you will have just what you need.

Conclusion

At the top of this article I tried to explain what I considered a CSS framework to be. Frameworks are something we should all be using, and all be collaborating on. Just because we have the ability to start from scratch, doesn’t mean we should. We’d be better off spending our time building the cool stuff on top of our projects that sets them apart from the rest; not tirelessly chipping away resetting CSS or building umpteen grid systems.

A framework should be a major part of your build setup along with grunt files and JavaScript libraries. Done right, it can be an amazing tool to get you off the ground; I’m sure if you needed jQuery for your project, you wouldn’t set about writing it for yourself.

I’m sure most developers have some kind of CSS out there they place in every project. So take that time and build it into a robust framework that can benefit you – and others.

Author: Matthew Fowles