An Introduction to Object Oriented CSS

With richer interactions and media heavy pages mushrooming on the web, creating web pages, which load faster and respond well has become a challenge. Separating the content, presentation and behavior of a page using HTML, CSS and JS, is not the only thing that front-end engineers have to concentrate on nowadays. The limelight is now on the performance of the pages, cleanliness and leanness of the code within, scalability and reusability of CSS, and the semantic correctness of the markup.

There are a handful of frameworks, techniques and approaches that are built towards this goal of maintainability, scalability and reusability of CSS. Each of them is having its own pros and cons. But, this is not a stage to elaborate on all of them.

This article is an introduction to implementing the concept of ‘Object Oriented Programming’ in building CSS for high scale websites and applications, with an eye on maintainability and reusability.

What is OO CSS?

The concept of ‘Object Oriented Programming’, is widespread among developers, and forms the basic for any modern programming language. Features like data abstraction, modularity and inheritance make it a favorite in coding large-scale applications.

Object Oriented CSS, as the name suggests, is implementing the concepts of OOP in structuring and building CSS rules, which are easy to reuse, thereby reducing the loading time and increasing the performance of web pages incredibly! The key point here is, to identify, build and style modular reusable ‘objects’ in a page, and to reuse it in multiple instances by extending them with additional features wherever needed. Here an ‘object’ refers to the basic HTML markup and its CSS rules. Apparently, here, the key challenge is going to be, identifying the ‘object’ and building rules for it.

This is neither a framework nor a technology, but an approach adopted in building the rules, so as to make the code more reusable, maintainable and scalable. You may already have been making use of this concept in coding your style-sheet for years, but may not be aware of this terminology :).

A UI engineer at Yahoo (‘Nicole Sullivan’ ) coined the term. She had made a number of presentations on the topic on various big stages (http://developer.yahoo.net/blogs/theater/archives/2009/03/website_and_webapp_performance.html) and is also included in a feature on Women in Technology.

Nicole, who has been hired by Facebook recently, for optimizing the CSS and web page performance, has been leading the way in implementing this approach in the pages for the social networking giant, and the results are to be seen. A faster loading FB, with significantly less response time! This is exactly what this approach of building CSS promises to give back. But again, like all other frameworks, this too has pitfalls and advantages which we shall discuss in detail.

Following are some key aspects in object-oriented approach to CSS building:

1. Create a component library
2. Separate container and content / Avoid Location dependent styles
3. Separate Structure and skin
4. Extend base objects using class names
5. Stick to semantic class names

Create a component library

This is the first thing to do, while building a OO CSS framework for your application, and this is the most time consuming process too. You will have to carefully study the screens of the app, and come up with the recurring reusable UI patterns, and will have to create a library consisting of HTML markup and respective CSS rules of all such components first. This may take some initial time, as you may need to filter out the components and find out the basic structure of a component, and its variations along different screens.

E.g. For a blog, ‘metadata (Refer to the marked area in the figure below)’ will be present in multiple instances of a page. After closer scrutiny, you will come to know that, all the metadata can have the same HTML markup, and the variations can be addressed using CSS (the font size, color, margin and padding are different in each of the occurrences of metadata component). Select a markup, as a base structure, in which you can accommodate majority of the elements that possibly can come in the particular component.

In our example our basic structure of the ‘metadata’ component will be:

Base Markup

1	<p class=”metadata”><a>Author namea>commented on<a>21-02-2010a>@p>

Base rule

1	.metadata{font-size:1.2em; text-align:left; margin:10px 0;}

Thus, ‘metadata’ can be now independently used within any other element in the markup, and will have a consistent look and feel, irrespective of where it is used. But as we can see in the figure above, there are multiple variations of the component. This we will tackle using CSS, and will be discussing in the following points.

This way, figure out all the reusable components, and create rules and markup, and group them separately in the CSS file. (It’s even fine to create a separate CSS for the component library, and then merge it with others later during deployment.)

Separate Content from Container / Avoid location dependent styles

This is one of the primary requirements of following an OO approach to building CSS files. The core idea here is to consciously differentiate the rules of containers and the content that comes within them, so that content can be plugged into any containers irrespective of their parents.

Often while building large-scale CSS rules there will be instances where a single component will be appearing differently in various instances, when put in different containers. One of the solutions adopted by front-end engineers, for addressing this problem was to assign location dependent selectors to that particular component.

E.g. With reference to the example used in the previous point, where there are multiple variations of the same component – ‘metadata’, each instance can be given location dependent rules by combining the base class ‘metadata’ with the relevant classes/IDs for the containers. i.e.,

‘metadata’ in a blog post can be styled as: .post .metadata{overriding rules}
‘metadata’ in a comment can be styled as: .comment .metadata{overriding rules}
‘metadata’ in a comment can be styled as: .comment .metadata{overriding rules}

The OOCSS approach advocates avoiding this type of usage. Instead extend the base class by adding more classes, thereby extending the attributes of the base component to match the variation. We shall discuss the concept of extending the base class in the following points.

Separate structure and skin

In the first point ‘Creating component library’, we discussed the importance of identifying reusable components, and building base classes and base structures for them. While creating those base rules, an important thing to keep in mind is to separate the structure and skin. In other words, while defining a base class in the component library, we should not create skin-level rules, like width, height, background images, border styles, etc, that can make the component more specific to a certain container.

E.g. For our base class, ‘metadata’ with the following rule

1	.metadata{font-size:1.2em; margin:10px 0;},

Adding more skin-level rules as below,

1	.metadata{font-size:1.2em; margin:10px 0; width:500px; background-color:#efefef; color:#fff;},

can make it more of a specific component than a generic one, thereby making it difficult to reuse it in many other containers, which would need it to be rendered in a different ‘skin’. Also another danger of not separating structure and skin will be the ‘Specificity war’.

Extend base objects using class names

As discussed in the second point ‘Separate content from container’, avoiding the usage of contextual selectors will make the content independent from their parent containers and hence will be truly usable across the application. So how do we instantiate the variations of the same object in different containers? What is the solution? Well here comes the concept of extending the base ‘object’ (again another term coined by Nicole Sullivan), by adding more class names to it depending on the context, rather than tightly coupling the object with the class names of the containers in which it is to be placed.

E.g. In the first figure of the ‘metadata’ object, where the same object needs to be rendered differently in various containers,

The HTML markup of each of them will look like:

1	<p class=”metadata commentmetadata”><a>Authornamea>commented on<a>21-02-2010a>@p>

2	<p class=”metadata postmetadata”><a>Authornamea>commented on<a>21-02-2010a>@p>

3	<p class=”metadata authorlistmetadata”><a>Authornamea>commented on<a>21-02-2010a>@p>

The CSS rules will be:

1	.metadata{font-size:1.2em; margin:10px 0;}

2	.commentmetadata{font-size:1em; margin:0 0 10px 0; color:#063070; }

3	.postmetadata{ color:#063070; }

4	.authormetadata{ color:#fff; }

This is a very simple demonstration, to comprehend the concept of implementing OO programming. As the size of the app becomes larger, the UI patterns will become more complex, and there lies the actual challenge and advantage of using such an approach.

Stick to semantic class names

A challenge in building CSS for high-scale web applications is to logically come up with meaningful class / ID names matching with the context and moreover making sure, they are reusable and still make sense. With the concept of ‘extending’ base objects, it’s easy to fall into the practice of creating ‘presentational class names’. Some easy examples are ‘leftCol’, ‘redText’, ‘midCol’, ‘bigText’, ‘bolderText’ etc. Such class names are not reusable and are a hindrance to scalability.

Always stick to logical and semantic class names relating to the logical meaning of the component, rather than its presentational meaning. It means, instead of giving the text block with a yellow background color, the class name ‘yellowText’, ‘notification’ would be a more sensible name, as it is a notification element that pops out to notify some activities within the system.

Pros and Cons?

Following such an approach of building CSS has its own pitfalls and advantages

Here are a few cases, where adopting such a framework ‘may’ backfire:

1. OOCSS is suited to really large websites / application which are filled with reusable components. It may not give desired results in smaller websites and applications. So decide sensibly depending on the size of the work in hand
2. If not smartly used, creating the component library can turn out to be a mess, and become a maintenance nightmare for other coders
3. Documentation is a must. Each block of code should be clearly commented out with the right points for other coders to absorb the concept, which otherwise can become too tedious in case of a knowledge transition

Some obvious advantages of adopting this approach are:

1. Less lines of CSS code
2. Cleaner HTML markup, with logically sensible class names and hierarchy
3. Semantic markup, means more SEO friendly pages
4. Far better page optimization, with much faster loading times, since most of the components are reused
5. Scalable markup and CSS code, where more components can be added into the library without disturbing other components, as the base objects are independent of any other containers
6. Easily theme-able layouts, since changes to the base object can completely change almost the whole presentation layer instantly