Object-Oriented CSS
If you don't consider how the code should be formatted, handling CSS may rapidly become difficult as web projects expand.
OOCSS stands for Object-Oriented CSS. The idea behind OOCSS is that you can reuse your HTML structures and patterns, implying less CSS to deal with in the long run. It makes your stylesheets easier and more efficient to add and maintain over time.
Before applying OOCSS principles, you might have CSS that looks like this:
Example 1:
.button {
width: 150px;
height: 50px;
background: #FFF;
border-radius: 5px;
}
.button-2 {
width: 150px;
height: 50px;
background: #000;
border-radius: 5px;
}
Step 1: Separate your structure from the skin.
The structure is the essential core element that makes the website look like it does. When looking at structure, you ignore the branding elements such as typography, colors, borders, and any other specific stylized features.
The structure of an application refers to things that are "invisible" to the user, such as instructions for element size and positioning. These properties include:
- Height
- Width
- Margins
- Padding
- Overflow
An application's skin refers to the visual properties of elements such as:
- Colors
- Fonts
- Shadows
- Gradients
The Example1 above contains a lot of repeated code to define the width
,height
, and border-radius
. This can clutter your stylesheet over time and lead to potential inconsistencies because it requires changes in multiple places. Using OOCSS, we can pick out the common patterns to all skins inheriting the same properties.
Here .btn-primary
and .btn-secondary
are skins and decorate the base structure created through .btn
.
If we abstract it, we can reuse the .btn
class and only need to swap out the skin classes in our HTML.
.btn-primary{
background: #FFF;
}
.btn-secondary{
background: #000;
}
.btn {
width: 150px;
height: 50px;
border-radius: 5px;
}
Here is what the Html will look like:
<a class="btn btn-primary" href="#">Submit</a>
<a class="btn btn-secondary" href="#">Cancel</a>
Step2: Separation of container and content
Containers are the things that hold the other elements. These are the usual structural things like <div>
, <span>
, <article>
,<navigation>
, and <sidebar>
. Then there is the actual content such as <img>
, <p>
,<input>
, and things like buttons.
As a general rule, styles should never be scoped to particular containers. Otherwise, you'll be unable to reuse them without applying overrides.
#sidebar {
padding: 2px;
left: 0;
margin: 3px;
position: absolute;
width: 140px;
}
#sidebar .list {
margin: 3px;
}
#sidebar .list .list-header {
font-size: 16px;
color: red;
}
#sidebar .list .list-body {
font-size: 12px;
color: #FFF;
background-color: red;
}
Now, here are the same coding instructions with the content and containers separated:
.sidebar {
padding: 2px;
left: 0;
margin: 3px;
position: absolute;
width: 140px;
}
.list {
margin: 3px;
}
.list-header {
font-size: 16px;
color: red
}
.list-body {
font-size: 12px;
color: #FFF;
background-color: red;
}
Some Guidelines For Implementation
Here are some things you might want to start doing to help you get into an OOCSS mode of thinking:
- Avoid the descendent selector (i.e., don't use
.sidebar h3
) - Avoid IDs
- Avoid attaching classes to elements in your stylesheet (i.e. don’t do
div.header
orh1.title
) - Except in some rare cases, avoid using
!important.
These are not hard and fast rules, but overall, these are good habits to develop and will lead to stylesheets that are smaller and easier to maintain.
Conclusion
You could certainly make the case that OOCSS would be overkill for smaller sites and apps. But as beginners, this will help you start thinking in terms of OOCSS in all your projects. Once you get the hang of it, I'm sure you'll find it much easier to get it working on more significant projects where the benefits would be more noticeable and relevant.
I will wait to hear your views on OOCSS or any other convention you use in the comments below. You can connect with me on Twitter