OOCSS — The best way to code reusable CSS in an easy way!

What about semantics and upkeep?

You shouldn’t care about being non-semantic. I care about what it means to upkeep.

The only way to make objects in plain CSS is to define non-semantic classes. However, this comes with some problems:

  • We have to change our HTML almost every time we need to change styles.
  • There’s not a safe way to access some of the DOM elements.
  • Besides the unmaintainable HTML, everything else about OOCSS is just great. Our CSS code is scalable and easy to maintain and reusing our abstract classes makes it easy to style new content.

So we code the parts in CSS and extend them in HTML. Could it get any better?

OOCSS & SASS — a match made in heaven!

If you’re familiar with SASS, I’m sure you’ve heard about the @extend directive. Thanks to placeholder selectors we can extend in Sass, creating semantic classes in CSS, solving our problem for HTML.

We must use placeholders as objects, and define classes formed only by merging them through @extend. This will result in an incredibly DRY CSS code. Let’s see an example:

/* The bad way */
a.twitter {
  min-width: 100px;
  padding: 1em;
  border-radius: 1em;
  background: #55acee
  color: #fff;
span.facebook {
  min-width: 100px;
  padding: 1em;
  border-radius: 1em;
  background: #3b5998;
  color: #fff;

Applying all we’ve seen and using @extend to mix base objects we can get clean OOCSS which is very easy to maintain and we don’t have to change the HTML all the time.

/* The best way */
%button {
  min-width: 100px;
  padding: 1em;
  border-radius: 1em;
%twitter-background {
  color: #fff;
  background: #55acee;
%facebook-background {
  color: #fff;
  background: #3b5998;

.btn {
  &--twitter {
    @extend %button;
    @extend %twitter-background;
  &--facebook {
    @extend %button;
    @extend %facebook-background;

This produces efficient code that we can use easily in our HTML:

<a href="#" class="btn--twitter">Twitter</a>
<a href="#" class="btn--facebook">Facebook</a>

Pretty semantic, right? Sass has solved our problem. Remember: extend and collect non-semantic parts on Sass if you want to keep a semantic, easy to maintain HTML.

Easy-to-Follow OOCSS Guidelines

It’s can be tough to nail down exact specifications because developers are constantly debating the purpose of OOCSS. But here are some easy-to-follow suggestions that can help you write cleaner OOCSS code:

  • Avoid descendent selectors (i.e. don’t use .sidebar h3)
  • Work with classes instead of IDs for styling.
  • Organize your stylesheet into sections, consider adding a table of contents.
  • Avoid attaching classes to elements in your stylesheet (i.e. don’t do div.header or h1.title)
  • Except in some rare cases, avoid using !important
  • Use a CSS linter (online version here) to double-check your CSS (and know that it has options and method to its madness)

Note that developers should still use IDs for JavaScript targeting, but they’re not required for CSS because they’re too specific. If one object uses an ID for CSS styling it can never be replicated since IDs are unique identifiers. If you use only classes for styling then inheritance becomes much easier to predict.

Moreover, classes can be chained together for extra features. A single element could have 10+ classes attached to it. While 10+ classes on one element isn’t something I’d personally recommend, it does allow developers to amass a library of reusable styles for unlimited page elements.

Camel case is also popular, for example .errorBox instead of .error-box. If you look at class naming in OOCSS’ documentation you’ll notice camel case is the “official” recommendation. There’s nothing wrong with dashes but as a rule it’s best to follow the OOCSS guidelines.

Benefits of OOCSS

OOCSS is a popular approach to coding for many reasons, here’s just a few of the benefits:

Site Speed

Cutting down on repetition helps applications run faster. CSS files have a habit of expanding exponentially as websites grow in complexity, thus increasing web page size. Specificity is important, but often CSS files contain way more information than is necessary. When using OOCSS, just follow the DRY rule: Don’t repeat yourself. Consequently, you’ll have CSS files that are smaller and quicker to download.


OOCSS allows you to freely mix and re-apply classes on different elements without much regard for their context. Therefore, instead of piling on tons more CSS each time a project is passed from one developer to another, newcomers to a project can reuse what their predecessors have already abstracted out.


Having fewer blocks of code makes CSS easier to scan, which makes editing and updating less of a hassle. By using previously specified styles for different elements, not only will your code work faster; you’ll work faster too.


Adding or rearranging HTML markups no longer requires you to rethink your entire CSS flow. This is especially helpful for larger ongoing projects.


When other programmers see your CSS, they should be able to quickly understand its structure.

Relatability to Other Concepts

Understanding the object-oriented methodology makes it easier to learn programming languages like Ruby. Conversely, anyone who already understands Ruby can quickly pick up OOCSS.

Disadvantages of OOCSS

Although there are many benefits to using OOCSS, there are a few drawbacks:

Increases the Number of Classes Added to an Element

As there is much more separation in the way classes are created, you may need to add multiple classes to an element to account for all of the styling elements. This can cause some confusion to those who aren’t familiar with OOCSS and can clutter your markup.

May Be Overkill for Small Projects

OOCSS certainly isn’t required for all use cases. For smaller projects you may opt to not use it at all and that’s completely fine. As mentioned above, a few of the main benefits are: scalability, readability, and maintainability. As projects grow, these aspects become harder to manage which makes OOCSS a great tool, however, these aren’t as pressing for smaller projects.

Requires a Learning Curve

It may be that other web developers or designers need to make adjustments to your code. However, if you’re using OOCSS and your co-workers aren’t familiar with it, this will require the need for them to learn how to use it before proceeding, which takes time.

Wrapping Up

I know there’s probably a lot of you out there that fear the OOCSS ideology because it appears to go against a lot of the so-called “best practices“. Never fear! Once you understand the benefits of using OOCSS, I have no doubt that you will convert.

1 2

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

All comments are held for moderation and only published when on topic and not rude. You'll even get little stars if you do an extra good job.

You may write comments in Markdown. This is the best way to post any code, inline like `<div>this</div>` or multiline blocks within triple backtick fences (```) with double new lines before and after.

Want to tell me something privately, like pointing out a typo or stuff like that? Contact Me.

icon-search icon-link