Last night, I watched a 49 minute presentation by Nicole Sullivan on something she calls "Object Oriented CSS" or "OOCSS." In simple terms, Object Oriented CSS is a methodology or framework (whichever you prefer) for organizing and extending your CSS in a way that is lightweight, highly performant, and easily used by developers at all skill levels. At least, that seems to be how it is marketed.
In the presentation, as well as on the OOCSS web site, Nicole's states that her framework revolves around two simple principles:
- Separate structure and skin.
- Separate container and content.
The first one, separating structure and skin, is not something new that Nicole is introducing - this is something that has been held as an "ideal" in CSS development for sometime. The problem is that not that many people (myself included) have the foresight and the dedication to follow it. Nicole's framework, however, sticks to this principle in its CSS file organization making it something that you no longer have to think about.
The second principle, separating container and content, is a much more interesting principle because is requires developers to modify content using (CSS) class extension rather than context. This is a problem that I touched on recently when considered the difficulty of contextual CSS with containers. OOCSS solves this problem to some degree by saying that if you need to change the rendering of a given element, you need to add an additional CSS class to it that defines only the differences in rendering.
Of course, contextual CSS is required at least sometimes to keep the markup simple and, in fact, the OOCSS framework itself uses some contextual CSS rules to define parts of the modules. And, just as I described in my blog post, this does cause rendering quirks if the modules are nested. This, of course, conflicts somewhat with the concept of separating content from containers, but as with all things, we must seek a happy middle ground that is a good balance of flexibility and usability.
I'm still digesting the things Nicole outlined, but there is something initially pleasing with the framework she has developed. I really like how the module markup never changes (except for additional class values) even as the rendering gets more complex. Granted, this leaves some HTML elements unused depending on the skin, but it keeps the markup very consistent which is ultimately more "team friendly" as well as future-proofed.
Anyway, it's a relatively short and thought-provoking presentation. I highly recommend that you give it a watch. There are aspects of that I want to put into immediate effect within my own CSS and application development.