Object Oriented CSS is a method of development as it pertains to the HTML and CSS relationships designed to reduce redundancy in CSS, primarily to make more manageable code. The idea is (basically) to take reused styles and assign them to individual classes, then the elements that use those styles take on that class, plus additional classes for the remaining styles.
First I’m going to address the issue with the name. True, Object-Oriented has an understood meaning as it applies to object-oriented programming, and CSS does not adhere to this understanding. Much of the naming convention with this method was, in my opinion and that of many other programmers, poorly chosen. When first learning of the concept, this can make it rather confusing, as you might be expecting to see correlation with OOP, when there is not much to be found. That being said, please judge the system on its merits, not its name.
One of the biggest drawbacks of this method is that, being style-driven (inasmuch as you’re encouraged to separate style chunks into element classes), it ends up putting a lot of the presentation into the markup. This is generally considered bad practice, as common consensus is to (as much as possible) separate content from presentation. However, some have expressed the theory that this common “best practice” is archaic and doesn’t solve any problems. However, it is increasingly common for the same content to be presented in multiple ways. For example, a website that uses media queries to present its mobile version using the same markup, or an XML or JSON file that gets interpreted into different formats altogether, such as HTML and PDF. Perhaps the most cited example is changing a site’s theme. In the event that the theme changes more than a few details and colors, classes will have to be changed in the markup. Although redesigning a site (with the same contents) may sometimes involve changing markup anyway, ideally it doesn’t at all, and it’s still bound to be much less when your markup is written semantically.
Many of the goals of OOCSS are excellent, though not necessarily new. Manageable code is obviously a good thing, and developers of all types should always strive for it. Planning out your project as thoroughly as possible, which is another practice this method encourages, helps a great deal, though obviously doesn’t require any particular method. Reducing redundancy also contributes significantly to manageable code, but there are certainly ways of accomplishing this without removing the semantic quality of the markup. You can remove a lot of redundant style declarations by using multiple selectors per block, which will admittedly result in the same selector being repeated in several places, but it’s not worse than OOCSS repeating the same classes over and over in the markup, and it’s decidedly better than repeating whole chunks of styling directives, both from file size and manageability standpoints. It’s true then that if you have many, many, distinctly different elements that reuse portions of the same styles, your CSS selectors will get out of hand. If that’s the case, and it’s not due to poor design, applying a class for a specific style may actually be preferable to pure semantics. However, I believe this should be the exception, not the rule. Another method to reduce redundancy for manageability would be a preprocessor like LESS or SASS.
Some of the specifics of OOCSS make a lot of sense as well. Relying to heavily on ID selectors in your CSS can create reusability problems. This doesn’t mean never use ID selectors, just use them sparingly. It also doesn’t have anything to do with whether you use ID tags for other things, like JavaScript hooks. OOCSS also recommends mostly avoiding use of the descendant selector. I agree with carefully examining your use of the descendant selector, and generally having a default style for elements, but there are also cases where nav ul or header h1 will be more practical (and semantic) than adding a class to the individual element that essentially describes the same thing as its location.
I’ve seen some detractors claim that you’ll end up with classes so specific that you’ll practically be writing the styles inline, such as class=”softblue-background black-text medium-text rounded-corners soft-shadow” While this is not true, and OOCSS does not encourage you to break down your styles that far, it is simply an exaggeration, not a complete misunderstanding. There’s no clear barrier on how far to drill down your classes, which makes sense because it depends on the needs of your project, but also may make the example above not too far off. Which also brings up the point that despite planning ahead, if your project grows, you’ll have to add, change, restructure, etc. This is true of any project, but when it involves replacing one class with two, or otherwise restructuring the classes, it means significant changes to the markup each time.
Ultimately, the usefulness of any method of doing anything ultimately comes down to the individual project. You may indeed have a project where it makes sense to build things in a largely visually-dependent way, giving styling choices to the markup, and the usefulness of OOCSS outweighs the usefulness of semantics. However, I believe these situations are extremely rare, and for most projects, the long-established general best practices really are best. Agree? Disagree? Let us know by joining the discussion below.
