Scalable and Maintainable CSS Approaches

Front-end developers working on large complex websites know the challenge of writing scalable and maintainable CSS. Even when working on small sites, skilled front-end developers take into consideration more than delivering a website to spec, but also the future adaptability of that site and other developers who may work on it.

Amidst the constant effort to develop CSS best practices, object oriented programming concepts have been finding their way more and more into mainstream conversation and thought process about css code.

This article assumes knowledge of CSS and introduces object oriented CSS along with 3 distinct approaches to execution. It is important to note that these are methodologies that seek to address a set of problems experienced in front-end development. Object oriented CSS provides (an often highly opinionated) way of thinking and approaching CSS development. Thoughtful practitioners have to be flexible — choosing or developing an approach that fits with the project and team they are a part of.

What is Object Oriented CSS?

The standard introduction to OOCSS for many has been the tutorial by Nicole Sullivan about the media object. Smashing Magazine also recently did a great in-depth OOCSS intro on their site. There’s also a OOCSS Concepts slideshow by John Hann. If your new to object oriented css you may want to review these discussions. 

At it’s core, object oriented css aims to increase code reuse resulting in a system of scalable code that is efficient and maintainable. OOCSS is based on 2 core principles:

1. 1. separation of structure and skin — layout and design styling are separate.
   Colors, borders and other visual characteristics are often styled separately from the core structure. This results an object layer and a skin layer for CSS objects.
2. 2. separation of container and content — containers should be able to be placed anywhere on a page and be able to adapt to the content they contain.
   This translates into avoiding the use of location dependent selectors: a sort of decoupling of the CSS from the HTML. Avoiding location dependence results in fewer CSS overrides and reusable components that can be placed anywhere on the page.

Three current expressions of OOCSS concepts include:

1. The OOCSS framework
2. DRY CSS
3. SMACSS

Each approach interprets OOCSS principles based on a different underlying philosophy. 

1. OOCSS framework

The OOCSS framework is a project on Github maintained by Nicole Sullivan. According to their Github page, the OOCSS framework is “a collection of code that’s built using the  OOCSS approach and is meant to help you get started. However, the framework is not the same thing as the OOCSS idea”. 

The OOCSS framework provides documentation and a code library. The code library contains CSS objects created by finding repeating patterns and abstracting them into a snippet of HTML, CSS and JS (if necessary). 

The framework website has a core guidelines list including:

1. Avoid the descendent selector. 
NOTE: the recommendation is not: don’t use it, rather it IS avoid it. 

2. Avoid attaching classes to elements in stylesheets. 

Instead of using a selector such as .sidebar h3, you would give the h3 it’s own class and then style the class itself.

<div class="sidebar">
  <h3 class="article-heading"></h3>
</div>

Descendent

.sidebar h3 { font-size: 20px }

Element in stylesheet

h3.article-heading { font-size: 20px; }

Class only

.article-heading { font-size: 20px; }

It’s important to note that there are also levels of strictness in the interpretation of guidelines of OOCSS. Some people will tell you you can never use descendant selectors or that you can never use an ID selector. In other words, almost every HTML element will have at least one class applied to it so that you don’t have to use descendent selectors.

<h3> 

becomes

<h3 class="h3">

What about semantic CSS?

.article-heading {}

is a descriptive selector. However, to become fully re-usable the OOCSS framework might suggest just using a medium heading class

.md-hd {}. 

There is some argument about semantics in all of this. Should classes be named after the presentation or the content within? With OOCSS you can make the choice yourself. Some people believe very strongly that classes should only be named after the content itself. On the other hand, naming classes (consistently) after presentation is a different approach to semantics. At its root, it is still semantic. It is communicative and it clearly communicates an expectation of the resulting behavior. 

Reusable CSS

The OOCSS Framework encourages avoiding location dependent styles. So rather than styling a whole page based on the body class you create smaller modules on the page and extend them with subclasses as necessary. This allows you to maximize reuse of code.

Reusability is also improved because of the OOCSS Framework encourages abstracting CSS structural styles and skin level styles.

.button { width: 200px; height: 50px; } 
.box { width: 400px; overflow: hidden; } 
.widget { width: 500px; min-height: 200px; overflow: auto; } 
.skin { border: solid 1px #ccc; background: linear-gradient(#ccc, #222); box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px; }
.skin-alt { border: solid 1px #000; background: none; box-shadow: rgba(0, 0, 0, .9) 2px 2px 5px; }

DRY CSS

While OOCSS Framework focused specifically on abstracting snippets of code, Dry Css focuses primarily on not repeating yourself. The DRY CSS approach was presented by Jeremy Clarke at ConFoo 2012 . The goals are similar but the approach is radically different.

The core recommendation of Dry Css is to group reusable properties, name them and then add all selectors to the group. This means that the objects created in DRY CSS aren’t snippets of HTML, CSS and JS but rather an object created of shared styles with many possible selectors.

Example:

#LARGE-TEXT,
#featured-headline, h1, .pull-quote {
  font-size: 20px;
}

This recommendation reflects the 2 principles that Jeremy says make good CSS:

• Keep style separate from content (Tags, classes and IDs should refer to the content not how it looks)
• Avoid specificity by harnessing the cascade

Compared with the OOCSS framework, DRY CSS argues that semantic HTML should be HTML that reflects the content.

The DRY CSS approach encourages thinking about how many objects share CSS values. It also allows you to edit those styles in “one place” because of the groupings. Jeremy also suggests that one of the benefits is that it “doesn’t require changes to HTML”.

I’m not convinced that this is entirely a benefit. If the HTML is out of your control, it is obviously valuable, on the other hand it doesn’t necessarily encourage thoughtful HTML structuring.

3. SMACSS (Scalable and Modular Architecture for CSS)

The third approach to OOCSS also shares goals with the OOCSS Framework and DRY CSS, but the implementation again is very different. SMACSS’ documentation introduces it as “a way to examine your design process… to fit rigid frameworks into a flexible thought process… to document a consistent approach to site development when using CSS.” SMACSS is all about developing a system and thought process. It recognizes that there is no “one-way”. Of the 3 approaches, SMACSS has the most detailed documentation. There is even a book you can purchase. 

The philosophy underlying SMACSS is:

• Increase the semantic value of a section of HTML and content
• Decrease the expectation of a specific HTML structure

SMACSS encourages

• Minimizing the depth of applicability. Thoughtfully decoupling CSS from HTML.
• Following consistent naming conventions

SMACSS defines 5 categories of CSS rules along with naming conventions: Base, Layout, Module, State and Theme. Rather than lumping all the CSS into one rule, the CSS pertaining to each category is meant to be separate. Additionally, Snook has defined guidelines for each category.

Base

Applies to: the defaults  
Naming convention: none
Selector guidelines: typically single element selectors
Selector example: h1, body, p, ul

Layout

Applies to: major page structures
Naming prefix: on ID selectors none, otherwise l- 

Selector guidelines: typically a single selector unless layout needs to respond to other factors such as shifting from a fixed to fluid layout
Selector example: #sidebar, .l-grid, .l-fixed #sidebar, .l-fluid #sidebar, .l-grid  

Module

Applies to: smaller reusable components of a page. Modules can be sub-classed.
Naming convention: named but no prefix, related elements in module use base name as prefix
Selector guidelines: only class names, avoid use of IDs or element selectors
HTML example: <div class=”box”></div>, sub-classed: <div class=”box box-notification”></div>
Selector example:  .box, .box-notification

State

Applies to: the state of an object
Guidelines: can modify appearance of layout or modules, indicates dependency on JavaScript
Naming prefix: is-
Selector example: .is-collapsed

Theme (depending on project needs)

Applies to: the visual skin. (colors, etc…) 
Naming: preferably located in a theme.css file removing need for additional naming convention
Guidelines: can override any of the other categories as needed

There is much more to SMACSS. To fully explore SMACSS methodology, I highly recommend reading the documentation by Jonathan Snook which is clearly and beautifully presented online or available as a Kindle book through Amazon

CSS and the future of front-end development

The approaches diverge significantly from each other, yet they share some common characteristics. Each requires abstracting design patterns into a reusable chunk of code (resulting in less total code) and seeing objects in the big picture instead of just seeing isolated pages. They demand consideration of the future in terms of scalability as well as others who will work with the code (code user experience?). Additionally, they encourage a decoupling of HTML and CSS to an extent - some more than others. This suggests embracing the single responsibility principle recently discussed by Harry Roberts on CSS Wizardy which says, “every module or chunk of code should do one job well and one job only”. The benefits of course being that your code is more portable, reusable and maintainable.

Most importantly for the future of our craft, all 3 approaches demand that front-end developers be critical practitioners as they considering the big picture, the quality of code and the future maintainability of the code. 

Does one CSS methodology win?

Out of the 3 implementations of object oriented CSS, I find SMACSS the most compelling and flexible. This is a personal choice. I know many developers will be attracted to other systems or to none at all. SMACSS offers clear documentation and guidelines which are easily adapted to your own style. SMACSS offers a systems and thought process solution rather than a library or framework. The architecture is a highly flexible middle-ground between the OOCSS Framework and DRY CSS, could allow incorporation of a framework and allowing avoidance of class-itis and avoidance of using deep selectors. All of which makes it ideal given the fact that I work daily in a team environment on a high-traffic site with a significant amount of code

Object oriented CSS critics

The 2 primary arguments I’ve heard regarding OOCSS are:

• it’s not semantic
• it’s making css too hard

The first primary crique of object oriented CSS I’ve heard is that it isn’t semantic. I’ve addressed this concern above, yet it bears repeating that semantics can be based on different underlying thought processes. It’s certainly important to critically consider the issue.

The second primary crique of object oriented CSS I’ve heard is that it makes CSS too hard. Writing CSS is “easy” but creating efficient, reusable code that scales well takes thought. I recently heard it suggested (as an alternative to OOCSS) that it was only necessary to put each CSS rule on one line and to group rules by name. Presto! Shorter line count and easier to maintain without making it hard like OOCSS. In my opinion, this is short sided thinking. 

There are many challenges introduced when working on large and complex sites in a team with with multiple developers and front-end developers writing CSS. The challenges demand having a system that minimizes errors, improves efficiency and provides guidelines for quality code. 

I suggest that even builders of small sites can benefit from trying the thought processes behind object oriented CSS approaches. Through the practice of abstracting code into reusable objects, applying the single responsibility principle and considering naming and categorization methods front-end developers learn to consider the system in it’s entirety. With OOCSS you have to think about the big picture. The end goal isn’t just to get a site working. 

No matter where you land on this topic or which methodology you choose, for the future of our craft, may we go forward as critical practitioners.

Further CSS Resources

Scalable and Maintainable CSS Approaches Part 2 & 3: OOCSS & CSS Pre-processors

Documentation:

OOCSS
DRY CSS presentation  
SMACSS

CSS Blog posts by other authors:

VANSEODesigns  has in-depth introductions to each of the systems.
CSS Wizardy on Github  has some great tips (take with a grain of salt)
Stubbornella has great thought provoking articles on CSS