close

Day 6: Getting to grips with OOCSS

Toby Howarth

As a front end developer/designer, CSS and HTML is the backbone to everything I do, whether it is coding up a PSD, theming a WordPress site or building something completely different (like a website for your mums mates knitting club).

With this in mind I try my best to keep on top of ways to improve my workflow and use of my time. Things like pre-processors and existing frameworks are great but getting the barebones right in terms of HTML layout and the amount of CSS is key.

I have been dabbling and looking into the principles of OOCSS of late and I have to say that for me it has been a real eye opener. Not only does it get you into a mindset which gets you thinking more about the way you code but keeps you focused on the naming of classes and the reuse of code throughout your project (things I’m sure you’re already doing).

This article is my take on getting to grips with OOCSS and shedding some light on what it is all about so please go easy on me as I take you on a journey into the world of OOCSS.

So what is this all OOCSS lark all about

OOCSS or Object Orientated CSS is a object based coding method which encourages you to reuse the code you write and speed up your coding process, therefore making your stylesheets a lot more efficient, less bloated and therefore easier to maintain in the future.

There are lots of things to keep in mind when you start coding up a site but when using OOCSS. It gives you a new insight into how you should approach your code and gets you thinking about the site as a whole and not just the page your currently coding.

In this Christmas special I am going to focus on separating your structure and styling to skin your elements more effectively and keep everything nice and tidy and easier for you to maintain. This process is all about making your HTML work harder but keeping your CSS clean and lighter (depending on the size of the site).

Let’s get started!

Structure from Style

We have all been there at some point in our coding evolution where we have had the same type of container on a site and we have named it differently each time and therefore had to write extra CSS for each container.

In hindsight this is stupid. It is stupid because if you take a look at that code now you will see that actually we could have separated out our code in a sensible manner and written a lot less. By doing this it allows you to have that element anywhere you like within your css and then you just apply a skin using a class name.

Make sense? No? OK here is an example for you. Say that you have a button that is used on your new site and it is featured across the site but it might change colour depending on the location and context. You might have coded this as follows:

The HTML

<a class="button-red" href="#">Click Me</a>

THE CSS (non OOCSS)

.button-red{
    width:150px;
    height:50px;
    background-color:#BE4D43;
    border:1px solid #7D4944;
    -webkit-border-radius: 10px;
    -moz-border-radius: 10px;
    border-radius: 10px;
    padding:10px 20px 10px 20px;
    color:#fff;
}

Pretty simple red button right. Now if you wanted a green button or a smaller button you might copy that code and change the CSS to reflect a new colour or size (old school me would have for sure).

By doing this your making work for yourself and bloating your CSS with unnecessary code. With OOCSS the idea is to keep the core base style (foundations if you will) of the button and add extra classes to style it or colour it.

Looking at that button it is easy to split the CSS and give it some baseline styles and also give it a universal class name (button is super original I know).

So with that in mind here is how your code will now look.

The OOCSS HTML

<a class="button button-skin-red" href="#">Click Me</a>

Core Button CSS

.button{
    width:150px;
    height:50px;
    -webkit-border-radius: 10px;
    -moz-border-radius: 10px;
    border-radius: 10px;
    padding:10px 20px 10px 20px;
}

And thats it for the core code style.

We have decided that our button will always be that size and have sexy rounded corners. Everything else is decoration and we can add these with separate classes, for example:

.button-skin-red{
    background-color:#BE4D43;
    border:1px solid #7D4944;
}

And there we have it a nice red button for use on your site. Hang on though your site is super colourful and you want to have some nice green and blue buttons as well.

To have these new colours all you need to do is to create a new style class and name it appropriately i.e. button-skin-green or btn-green. The class is up to you but keep it easy to use and think about what other developers would think if they saw your code.

Now with that in mind we can also set new base styles for smaller or larger buttons. To do that we just create a new button-small for example and tweak the sizing. The skins don’t need changing as they will apply themselves beautifully to your new size classes as they are not dependant on any widths or heights etc.

So enough with buttons, what else can we do?

Widgets are go

The example above shows the use of OOCSS with buttons but we can of course apply this logic to any other elements in your HTML. A good example is that of widgets or sidebar items (or any element in fact). The premise is the same so lets take a look at some examples.

Widget HTML

<div class="widget">

</div>

There we have a class called widget which we are going to use across the site in sidebars or maybe under content.

First thing to do is to look at the designs and ascertain what this widget looks like across the site. For this example we know that the widget will have the following base size:

.widget{
    max-width:300px;
    min-height:200px;
}

The widget will be 300px and we will throw in a min-height but we know that this widget will be longer depending on content. Of course we would remove the min-height based on content because it could be smaller, but for this example we will keep it simple (and there is no content its just for show).

On looking at the design again we can see that every widget has some key baseline styles so for that we are going to create a class (in this example we are keeping it simple and calling it skin). We could of course call it widget-skin-base or box-skin-base if we wanted to be smart.

.skin {
    border:3px solid #5897AD;
}

I know only one style right, but this style is consistent and by creating a class it saves us typing it every time across all our other “skins” AND it also means we can change it once awesome I know!.

Now we have the baseline we can create some other classes to add other styles to the widgets depending on the design. Again as an example I have included a few variations in the demo but here are 3 simple ones.

.skin-pattern{
    background:url(data:image/  png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAYAAACp8Z5+AAAAJklEQVQIW2P8//9/GgMUMDIyMjDCBEAcIBsiAOOAFDICcRpIBgYAzkgTlE9OeQoAAAAASUVORK5CYII=) repeat;
}
 
.skin-color{
    background-color: #CDDDEC;
}
 
.skin-shadow{
    -webkit-box-shadow: 3px 3px 2px 2px rgba(188, 188, 188, 1);
    box-shadow: 3px 3px 2px 2px rgba(188, 188, 188, 1);
}

So we now have the 3 flexible main styles which can be applied to any widget on the site.

The beauty of this is also that we can combine the classes on a single widget. So for example we can have .skin, .skin-color and .skin-shadow on one widget.

By doing this it enables us to chop and change the classes in our HTML without changing any CSS. However if we decide later on that the .skin border is too narrow we only have to change one line of CSS and it will be reflected across the site with those classes.

So as you can see widgets benefit greatly from the skinning as you can write less CSS and make that damn HTML work.

On Closing

So there are a couple of short examples of how you can apply OOCSS to elements on your websites to create more efficient CSS. I hope these explanations and examples have given you an idea of how the OOCSS principle of Skin and Structure helps you code faster in the future.

A lot of you might well be reading this and thinking that is how you have coded already and that’s great. And as with all coding practices the bottom line is to use it as you see fit and to adapt it to get it to work within your workflow.

Now I have written this using tasty vanilla css but Sass and LESS etc all lend themselves beautifully to this as you can define your brand colours as variables for example and then there is even less code changing.

Here’s 2 key points I hope you will take from this article:

Reuse Reuse Reuse – Write your CSS once then make it work all over the site. By doing this you can shorten your style sheets and speed up your sites. Less CSS used more across the site is a good thing as it allows your site to be modular and changing that one line feels so much better than searching all over the place for every instance of that stupid border:1px dashed #222.

Make your HTML do the work – Content is King but Classes are the bomb and take that HTML code and stuff it with classes to keep your CSS lean and make your HTML do all the work. Obviously don’t go crazy like 100 classes on one element I mean come on who does that. But use enough to speed up your CSS and make the site as flexible as possible.

With those 2 things in mind go forth and concur and if you have gotten this far then thanks for reading and I hope you all (well both of you) have a great Christmas and New Year!