oocss is crap
For the longest time I didn't mind all the oocss talk. When the term was first coined I quickly glanced over the basics and wrongly assumed it simply reiterated something I'd been doing for years. Lately the methodology has been gaining in popularity though (read Nicolas Gallagher's post for more information), which called for closer inspection of what was being suggested. Basically, I'm appalled by what I read and I hope I'm not the only one.
on semantics
Sure enough, the concept of html semantics is somewhat vague. Even though it's been a hot topic for years, there isn't really a definitive solution, hence why so little tools exist to make full use of semantic html code. For a while we relied on classes (microformats) to convey semantics, html5 introduced microdata as a baked-in substitute and the html elements themselves have their own natural semantic meaning. These days microdata allows us to define extra semantic value, not related to the simple nature of the content but tied to its contextual meaning (what am I and where do I belong).
Microdata can be used for styling (though it's overly verbose), data- attributes can be used as javascript triggers. Suddenly we find ourselves in a situation where classes are losing their appeal, oocss makes good use of their sudden lack of function to hijack the class attribute and use it for skinning. The question is of course: is this a good idea (in the long run).
on oocss
The idea behind oocss is to define visual styles tied to a single class name, then apply this class to all the elements that need this style. This goes against everything we've learned the past 10 years, but that in itself should not be a reason to discard the technique. It should however throw up a few warning signs, because obviously we haven't been preaching the semantic use of class names just because we thought I'd be a fun thing to do (and nothing else was going on anyway).
The 'oo' in oocss comes from extending and mixing different classes, a rather simplistic view of 'oo' but it sure helped to spread the word. While clearly a strength, it's also a weak point of the entire setup. Consider the following:
.class1 {... color:#000; ...} .class2 {... color:#fff; ...} One big problem with oocss that immediately arises is that conflicts between different skins are much more common compared to writing regular css. As we are allowed to mix and match different base classes, we quickly find ourselves in situations where properties defined in classes with similar weight are fighting for dominance.
While css provides a mechanism to fix this (the last class in the css source wins), I consider this to be a necessary part of css error handling rather than good coding practice. If someone rearranges your css file, things are bound to break, which hints at the very poor structure of your css.
on back-end implementation
Probably worse is the strain oocss puts on back-end implementation. In certain cases (inhouse development of big sites) it may not be too bad, but for other sites it means that the html a cms spews out has a very weak link to logical components, rather it is linked to styles. If there is a difference in style between two components, this means the component needs a different html output. Where before this used to be a css problem only, we are now spreading responsibilities between back-end, html and css.
Not only that, simply skin updates also impact the html, meaning more possibilities for things to go wrong.
on oohtml
The reason why I didn't pay much attention to oocss at first is because I've been using similar concepts, only based on html patterns rather than css patterns. Define base classes for different (semantic) components, then extend them with additional classes to make variants. Only use semantically sound class names rather than names that hint at skins.
In the long run, this would allow us (and really, I'm talking foreseeable future here) to develop single component frameworks that takes care of all the back-end and html work. Building a site (using a whitelabel css for your framework) could take hours instead of days, the rest is just css work. As long as you make every element identifiable (which is not the same as adding a class name on each html element), there shouldn't be any problem.
But what about the css you say? Well, Nicolas has the following to say:
However, even with the help of a pre-processor, my preference is to use the multi-class pattern and add modifier classes in the HTML.
It's nice to have preferences, but I'm pretty interested to hear exactly why he prefers the oocss way. People who used less and sass before will recognize that oocss is little more than a html-intensive way of incorporating mixins. Mixins can do pretty much the same thing as oocss, only you don't need to bastardize your html code to get the desired result.
conclusion
Screw oocss, long live oohtml. Write your html code with semantic components and variants in mind, use mixins if you want to reuse css code. It benefits back-end implementation, keeps your html predicable and clean and maintains the separation between content and styling. It's nice to challenge existing ideas once in a while, but that doesn't mean that the result is worthwhile. For now, oocss might seem somewhat attractive (with mixins not being part of the official css spec), but in the long run it's another one of those faux best practices that will do more harm than good. Let's not fall into that trap again.