After reading an article about OOCSS (Object Oriented CSS) I was left a little numb and confused to be honest. I’d advise you read the full article before reading what follows.
The idea is fairly simple – write your CSS using a “bottom up” approach, as opposed to a “top down” approach, treating your elements as “objects”, using mainly classes, as opposed to IDs. The idea of this is to make classes more reusable and to encourage a greater css granularity architecture. The overall theory behind OOCSS is something I don’t dispute in the least, if anything it’s simply good practice when writing a CSS file.
For me, the whole article borders on the pedantic to the outright pretentious.
Firstly, I’m not a fan of the name. “OOCSS” implies a link to OOP (Object Orientated Programming), which it is not. I can see why they’ve named it OOCSS as I guess multiple classes could be similar to inheritance, an element on your page as an “object”, classes imply reusability etc. As a web developer, who uses OOP I was instantly put on the defensive, thinking “OOP for CSS, wtf”. I understand the name is simply a paradigm, but it sends out all the wrong signals for me personally.
Apologies if this article turns into a bit of a rant…..
Descendant CSS Selectors
OOCSS seems to have a odd rule whereby descendant CSS selectors (E>g. .foo h4) are suddenly not allowed. Instead, to adhere to OOCSS principals you need to split the this into two separate classes and apply both classes within your HTML code:
<div class="button-basic button-skin"></div>
Both methods – using a descendant selector and two classes – are perfectly valid for me.
CSS Class Abstraction
One of the ideas that I don’t agree with the fact that the article and whole concept implies that more class abstraction is good. People still learning could read into this idea the wrong way and (worse case scenario) end up with a plethora of abstract classes that produces some awful HTML:
<div class="padding center-element block text-italic floated-right"></div>
I won’t go into the debate about speed of selectors either, as the article is little one sided here. Giving preference the use of classes over IDs is not a good way to go in my opinion.
OOCSS Performance Benefits
Another major selling point of OOCSS is that of site speed – which is of huge concern to web developers nowadays after recent Google changes, citing page speed as ranking factor. This part of the article is null and void for me as it’s so obvious. Small style sheets will result in smaller css files that download faster – that’s pretty obvious. Although after the CSS file has been gzipped there wouldn’t be a great deal of real world benefit. Saying all that however, OOCSS is something the majority of good developers do anyway ….
OOCSS – Already Used …
For me, OOCSS is an acronym someone has given to a technique they have suddenly realised they use, after comparing it to OOP – a fancy name if you like. It’s an acronym I imagine will be very common on CVs.
After reading the article I wondered why it existed in the first place. OOCSS is something any designer/developer worth their salts does by default after a longer enough period of time. One of the biggest sayings when relating to good CSS is “don’t use ID selectors for everything”. It doesn’t make a great deal of sense when you’re learning, but as time goes on you’ll realise that some commonly used IDs could just as well be a class – whallah, you have yourself the beginning of OOCSS. For instance, in pretty much all my projects I have a class called input-wide that one applied to an input field, makes it longer.
Hell, when I was first learning CSS years ago and ran my (awful, naff) sites through the W3C CSS Validator popped up a warning mentioning redundant CSS that could be better served using a class instead of ID – I never heard one mention of OOCSS then either.
To conclude, I’m not against OOCSS per se, I’m against the way it’s been described in the article as something new and revolutionary. In reality, everyone uses it, unknowingly as it’s simply a collection of best practices. The article would have a made a lot more sense if it was titled something along the lines of “CSS Best Practices”, as that’s simply what it describes, nothing more or less.
For me this whole area complicates CSS. Personally, I’ll keep using LESS for rapid development of layouts on multiple devices and as a starting point for my CSS – which is just what I believe a CSS Framework should be – a starting point, not a long list of “do’s and dont’s”
I’m sure some people will totally disagree with me on this whole topic, so I apologise in advance. At the end of the day it’s a hugely subjective topic 🙂
I’ve been thinking the same thing since hearing about this whole OOCSS thing. OOCSS is basically DRY: Don’t Repeat Yourself. Re-usable code should be put into classes, and as you grow more experienced you will start putting classes on just about everything. Do I still use IDs when appropriate? Hell yes I do, and people should stop saying to stop using IDs. All features of CSS should be used when necessary.
Yep, totaly agree. I honestly hate things with a passion that unecessarily make something simple, complicated.
I completely agree. You can sugar coat everything. All being said, know what you are doing, and memorize selectors rather than the dumb acronym.
Hi
My opinion is that the oop css just complicate the things.
It is fine with the current standards selectors, with the general properties.
To further illustrate how OOCSS can be used, I’ll use something similar to what I did on my site’s recent redesign . After coding the inner header element on my site, I realized that the basic structural styles for the inside of the header could be reused on other elements on the page.
That’s plain CSS and specifically, the “cascading” part. Nothing OOCSS about that my friend 🙂