Skip to content

Object Oriented CSS, SASS, and HAML

I surprised myself today when I opened up my first HAML document to edit. How have I not used this? However, my reaction wasn’t the common “Whoa, AWESOME!” it was more … “Whoa, this probably allows people to write a lot crap since they have less idea of what they’re doing.”

I’ve fallen in love with Object Oriented CSS (well, I love object-oriented most things … I semi-flipped my shit when I realized that’s essentially what non-relational databases are doing, but I digress …). 

Object Oriented CSS, the wiki says it best:

It’s an approach for writing CSS that’s fast, maintainable, and standards-based. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

I see OOCSS being a topic among people interested in standards, who want to bring reusable, efficient coding into the front-end space.

On another note, I see lots of developers flipping their shit over HAML (streamlined markup), SASS (CSS preprocessor/variable support), and Compass (mixins). 

I enjoy SASS and Compass for variables and mixins. However, SASS easily lends itself to writing redundant CSS, since you’re essentially writing shorthand CSS that then has the possibility to bloat in size for the end user (see On CSS preprocessors). So while I like Compass for mixins and SASS for the variables, I generally only use them to support planned coding.

Then I saw HAML. An example HAML doc looks like this:

    #date= print_date
    #address= current_user.address

It’s possible for OOCSS and HAML to all play nicely. How do we do OOCSS in HAML?

    %p Here is some text.

… It’s not hard, and with very little discipline, very doable in day to day coding. In the above example, the HAML generates the following:

<div class=’unit size1of4′>
    <p>Here is some text.</p>

Not bad.

Any opinions on using preprocessors for styling and markup? Are you working with OOCSS? What are your thoughts?

One Reply to “Object Oriented CSS, SASS, and HAML”

  1. I love how OOCSS addresses CSS bloat, but I still bristle at the presentation-specific classes. I’ve found that Sass addresses this nicely and has the tools to solve the bloat issue you mentioned. It’s true that poor use of mixins will lead to unnecessary duplicate code, so I’ve found that a good practice is to only use a mixin if that mixin changes the output css in some way. In other words, it doesn’t just spit out css without doing some operations on a variable. If I follow that rule then the output will always be unique css. When I need to simply apply the same styles to multiple selectors, as I would with OOCSS I can use the @extend directive. Which does exactly that. It’s just as easy to write as a mixin or easier, and helps to keep the css very clean.

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.