Beyond OOCSS with Sass

Learning more about Object Oriented CSS (OOCSS) by Nicole Sullivan was a game changer in my front end development career. It help me concentrate more on the selectors that I was using and how they could be reused again and again. As a result, I could reduce the bloat in my stylesheets and DRY out my code. OOCSS, in addition Jonathan Snook‘s SMACSS and a recent article by Nathan Ford on 24ways, have changed the way I write CSS for the better.

Then there was Sass…

That is, until I learned about Sass. Sass has taken CSS development and placed it in the realm of programming. Instead of writing out rules and properties, you’re now writing functions and variables that can easily be extended further with OOCSS.

What’s New

I’m sure most of you are already working with Sass and writing custom mixins, placeholder classes for @extend, and variables to keep values consistent. This isn’t an article about the best way to write things, instead it’s an idea of how we can use the concepts of OOCSS and apply them on a stylesheet level, rather than selector level.

Extending OOCSS with Sass

So let’s imagine we have an application with a central set of functionality. That functionality uses a consistent set of HTML and CSS. The catch is that this application needs to be skinned for each new client, meanwhile, new iterations of the application are constantly being produced.

This sounds kind of like a maintenance nightmare, right? Say we publish a new feature with new styles, how do we distribute those new styles easily without overwriting existing CSS, and not simply slapping it at the bottom of an unrelated stylesheet? Here’s where my concept comes in.

Consider the directory structure below and its proceeding compilable SCSS file.

Directory

  • CSS
    • SCSS
      • _global_reset.scss
      • _global_variables.scss
      • _local_variables.scss
      • _media320.scss
      • style.scss
    • style.css
  • index.html

style.scss

//global variables
@import 'global_variables';

//local variables
@import 'local_variables';

//html resets and base CSS
@import 'global_reset';

//mobile first CSS
@import 'media320';

The global variable partial will include default colors, margins, padding, font family, etc, whereas the local variable partial will include only the variables from the global variables partial that it needs to modify. Consider the prototype programming pattern where you have a set of options, but when the function is initialized, the user can pass in their own set of options. If no variables are specified from the user, the default variables pass through.

This is just an initial idea of how to better extend the concept of OOCSS to a stylesheet level. I’d like to experiment further with programming mixins. Consider the example below.

@mixin init( $tabs: false, $accordion: false ){

  @if ( $tabs ){

    #tabs { display: block; }
    // more tabs styles

  }

  @if ( $accordion ){

    #accordion { display: block; }
    // more accordion styles

  }

}

@include init( $tabs: true );

This way if the client wanted to add an accordion to their application, all you would need to do is find the @init mixin and pass $accordion: true. Now your CSS will include that block of selectors dedicated to the accordion. Now we can keep a styleguide with all elements styled and ready to go, but only include the selectors we need for a given project.

With Sass we can include a rich set of features and styles with a few sets of variables and our “init” function.

So, what do you think? Do you see this as being valuable? Does anyone with more experience with Compass know if it has something similar? What sort of features would you include in your init function?

posted in: Front End Development
tagged: , ,

2 Comments
  1. Mason Wendell

    I like the idea of an OOCSS init mixin, and I think this can be made a little more flexibly. Perhaps write a mixin for each widget in your library so you can modify them a little more independently and perhaps keep a library of setup styles for things like a tabs widget. Then you still call the desired mixin from within your OOCSS init mixin.

    Reply

    • Pete Schuster

      I agree, I think you could put mixins within mixins to create a pretty serious algorithm of styles and selectors.

      Reply

Leave a Comment

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