There are numerous shiny looking CSS methodologies/patterns, and they all have their positive and negative points. Over the next few weeks, we’ll run through some of the more popular options, giving code examples where necessary.

I’ll list three user examples and try to determine whether it’s good for that use case. Our three users will be:

  • Single user/hobbyist/lone-ranger (Alex)
  • Small agency/friends collaborating/3-4 developers (Tuco)
  • Large agency/corporation/5+ developers (Mary)

Using any CSS organisation technique is better than nothing at all, however this should give you a better idea of what may be the best option for your particular situation.

This week, we’ll be starting with:

##Object Oriented CSS (OOCSS)

If you know an OOP language, this might sound like bees knees - and you wouldn’t be wrong.

In short, OOCSS is about creating modular components that have singular concerns that can be swapped and shared amongst other CSS modules.

In more detail, this means you should be creating your CSS classes like you would your OOP classes. Your class should define what it does, and only what it does</a>. It shouldn’t know about anything else, or expect styling from any other classes to work.

An example of how you might do this in plain ol’ css:

.form {}
.form .control {}
.form .control input {}
.form .actions {}

Here we have a form object, and styles that are only applied to elements with a parent with the form class

In SCSS/SASS/LESS this can be accomplished with mixins. A mixin is basically a block of CSS that you can include wherever you like. An example of using a mixin in this way:

@mixin form
  .control
    input
      // Styles
  .actions
    // Styles
.form
  include form

####Good points:

  • Lets you be DRY (Don’t repeat yourself)
  • You know when you create new styles, the code isn’t going to unintentionally affect other styles
  • Helps with organisation - you should be able to easily find a CSS module that does the thing you’re looking for
  • Very easy to maintain as you don’t need much knowledge of other CSS code to make changes

####Bad points:

  • Modifying modules could have unexpected changes in places where the modules are used or if they are not used as you might expect
  • Making variations of modules adds complexity and could mean you will have very similar code in multiple places

###Who should use OOCSS?

Alex - Yes
Whether Alex is building a little app to realise an idea, or building a longer-lasting project, having code in reusable modules is going to make the initial development quicker. Reusing code, and any maintenance will be a breeze. The negative points won’t apply so strongly to Alex working alone, because they should have a good idea of what the code does - as they wrote it!

Tuco - Yes
As long as the whole team are happy using modules, and ensure they clearly communicate what modules they are creating, then OOCSS is going to make the team’s lives massively more enjoyable. Taking someone else’s module and incorporating it into your own code is very satisfying, and seeing someone else use your module in their own code is equally rewarding. Ensuring everyone knows what modules are available, and being vigilant on testing changes when modifying modules is imperative.

Mary - To an extent, yes
Having modular code is great in a smaller organization as it’s much easier to communicate what can be reused, where it’s currently being used, and what it should be used for. In a larger organization, the reality is that there are more people, creating more modules, with more modules available. It can get messy quickly. So where can Mary use OOCSS? Any base CSS or commonly used snippets can be moved into modules. Ideally they should either rarely change, or they should be so small that they won’t need to change often.

Further reading: github.com/stubbornella/oocss/wiki

###Next week

We’ll cover SMACSS (Scalable and Modular Architecture for CSS) next, so stay tuned!