Object Oriented CSS (OOCSS) By Nicole Sullivan
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.
Reader Comments
I use an awesome Ruby Gem called LESS. It really allows you to write CSS is a way that makes sense, but then compiles it for you to standard CSS.
It is worth taking a look at. The only downfall is that if you don't use ruby for dev, it is adding another step to production. But it is a step worth taking IMHO.
http://lesscss.org/
@Brandon,
Very interesting! That looks quite cool; and, in fact, it looks like it addresses a"wish list" item that Nicole mentioned in her presentation. Specifically, she wanted an easy way to "extend" classes from within the CSS itself. It looks like LESS does just that the mixins. Thanks Brandon, this looks like something worth investigating.
While I agree with many of the points she makes, I can't agree with all of them. Specifically, my biggest gripe is that her approach assumes you have control not only of the wrapper/template CSS, but also the ability to reliably apply named classes to body content. In effect, she negates one of the primary benefits of CSS to begin with: the ability to set a default style so that you can drop content in place and not have to worry about styling it (which includes adding named classes.)
I would also argue that the methodology she espouses is very useful for really large sites, it's not so applicable to small sites. Essentially, she's talking about an MVC framework for CSS. And just like MVC for CF (or any other language), there are places where it is required, places where it might be helpful, and places where it absolutely should not be used. Just like you probably wouldn't use FuseBox and Transfer for a single, standalone contact form, you're not going to need this level of CSS for anything less than a huge portal like Yahoo, Amazon, etc.
So ... long story short ... she's talking endgame stuff here. It's useful to know, and maybe useful to have in mind, but might hurt you if you pay too much attention too soon.
I think I agree with Rick. What Nicole Sullivan is advocating benefits monolithic institutions the most. But how each person benefits the most from the web comes from the open access it affords everyone. We benefit the most from videos passed around of politicians making campaign speeches calling peaceful audience-members "mukaka." I think our best labors in accessibility are spent advancing that kind of awareness, not in consolidating power.
Her hierarchical-structuring creates obstacles to human-readability of the code. I include contextual CSS because not only does it cut class-count, it allows me to review more of its structure in my personal field of vision. If your CSS is so huge that you need to tolerate structural layers obstructing your comprehension, you may be operating from a need for control I have yet to develope any sympathy for. Or maybe you just don't know what you're doing.
@Rick, @Mike,
There are certainly things that I was not in agreement with as far as her presentation goes. For one thing, I don't care for her abbreviated class names. They are too short and a bit *too* generic for me.
I also didn't agree with the idea that element shouldn't be considered for things. She gave the example of an "error" class. You shouldn't write:
p.error
... but rather:
.error
... because in the future, someone might want to make the error into a DIV that has its own sub heading and list structure. At that point, we are trying to me "error" too generic; it seems crazy that somehow something in ".error" could still make sense with "div.error" as the two have completely different layout and semantic intents.
That said, I think the OOCSS framework does force you to think about consistency and organization which I always useful on any project, even small ones. And, as with many frameworks, it seems like a lost of the benefits come from working with teams where there has to be consistency for the app to stay maintainable.
@Rick,
I don't think she has an issue with default content styles - at least that's not what I came away with. And, if you think about your site in terms of her "lego blocks", the structure should exist to proliferate consistent styles.
But again, as with many things, it might seem much more simple in presentation and MUCH more complex and frustrating when you go to implement it :)
I think the pretense that mark-up can be "programmed" is a good example of how a little intelligence can be a dangerous thing.
I tell people what I like about assembling web pages is that it's a lot like playing tetris. If it would mean anything to them, I would go so far as to tell them it's like playing tetris through a straw.
Programmers who impose their programming practices and idioms on mark-up get in my way. They make the mark-up all "straw" and tetris-block unfriendly. It's a pretense that only creates disadvantages. I think Ms Sullivan is employing analogies and practices that won't be reconciled with the lego-blocking she intends, because the labor to reconcile them is all "straw-work."
@Mike,
I am not sure I follow the "straw" references. I think a lot of it, again, comes back to this idea of working with teams and following a style template. Basically, not letting each developer re-invent the wheel, but rather choose from an existing set of elements to which content tweaks can be made.
My straw analogy refers to how the browser literally receives each file in a sequence of bytes or bits. If people reviewed webpages something like the browser received them, it'd be less like the web we know, and more like knowing the web through lynx.
Optimally, the styling should be invisible to all other development. If your styles never allow your stylist's collaborators to work independently of style-considerations, you either have miscast your stylist, or you are handicapping him or her (perhaps by imposing programming-practices in the CSS to open its access to programmers, and close its access to the people practiced in assembling 1-dimension code interpreted to display in at least 2-dimensions.)
Maybe I can be clearer if I refer to a specific example.
I coded the first draft of 12-or-so ready-made website templates for a major hosting company, offered as part of their suite of comprehensive hosting services. Each template came in up to 4 color-themes. 36-48 templates total. I cut-up the background-chrome from the PSDs, and I built the templates in such a way that the color-varieties were coded identically to each other -- except for the class of the body. Change one class, get a whole new color variety, with differently-hued chrome.
If I had coded the CSS the way Nicole Sullivan seems to be advocating, the number of people who could glance at the code and do ninja-backflips through it to customize it further would have gone from one to zero.
Now, what happened to my code was that it got butchered. I passed the project back to either the designer or the project manager, showed them how each template could invoke another color-variety by changing one class -- and the programmer who eventually got it only saw disadvantages to linking a stylesheet. So he hacked the templates and loaded the stylesheet into every page as an include. As well-structured as the CSS was, that I could at a glance zoom-in and make adjustments, it was still a fricking huge stylesheet, perhaps doubling or tripling the page imincluding it. I don't think I would even have minded if he could have intuited that all the "green" (and orange and red) classes -- quarantined in their own section -- were worthless on the blue page.
Because the programmer only saw disadvantages to linking a stylesheet, what was an example of best-practices instantly became an example of worst-practices. And that sure as hell wasn't the fault of my work.
All the programmer needed to hear from me was that all the color-varieties were identical except for one class change. He didn't know better, but that didn't stop him from assuming he "knew better." If he was curious enough to simply ask, I would have told him. I saw the best front-end coding in the internet's first generation destroyed by madness, starving hysterical naked dragged through the text-editors of programmers looking for an angry fix, and instead of enabling their control, Nicole Sullivan's time would be better spent kicking them.
@Mike,
I don't think Nicole is against easily swappable skins. In fact, from what I gathered, she is all for that; only, rather than changing the body class, she would simply swap out the skin-css files. I think this will accomplish the same thing.
As far as people coming in and hacking the code - that's a whole other problem altogether :) I don't know how you stop that; and, if you are passing your code off to someone else to be used going forward, I think you can only wish and hope that they don't mess up the structure you came to write so well. No framework will stop that worry.
For the kind of code-butchering I referred to, I know what the fix is: you cut the pretense that HTML and CSS are programmable.
I think maybe 95%-98% of the CSS anyone will ever need could be documented in 4-8 pages in a manual. 20 tags represent maybe 95% of the HTML expert coders use. A good secretary knows more than the best front-end coder. A good photoshop-operator knows way more than the best front-end coder. But there's still somehow a formidable barrier-to-entry to front-end coding.
If you look for it, every couple of years you'll come across a news story about some guy who's asking his surgeon, six months after he's been given his sight, to blind him again. The blind guy goes from a completely one-dimensional world, where nothing exists for him, like the furniture in his living room, until he stumbles across it, to a spacial-world, where there's a tiny airplane hanging outside the window of the car he's riding in he's told is carrying a boatload of people and is traveling 500mph. He can't take it.
This kind of dimensional-jump -- between the linear code and the spacial display of the page -- is the barrier to entry to the best front-end coding. That's it. And no quantity of programming expertise will ever compensate for this very simple thing most people find counter-intuitive.
The art of war refers to how artists can spin their entire palette from 5 colors, the 3 primaries and b&w. When someone tells me to get rid of my 5 colors, and I need to not mix so much, but from, say, 6 colors -- they have no business approaching me from a standpoint of knowledge. They don't know. Front-end coding is just not that challenging. Smothering the not-very-challenging development of a knowing-class of technician is not the answer. It's like trying to render commercial industry independent of secretaries. It's goofy.
@Mike,
I don't think front-end development is all that easy. In fact, the more complex a site or an application gets, the more challenging it gets. Suddenly, issues that you thought would not be an issue are. Names that were supposed to be specific can start to get used generically; hence, why you'll see many times a list of NEWS items that has the class "faq" or something like that.
I think as applications get more front-end intensive where the CSS / Javascript becomes a programming language in an of itself, it will definitely get much more challenging.
"...issues that you thought would not be an issue are."
Yes, as the 80/20% rule implies, out of a suite of plausible solutions, the best solution will be 4 or 5 times better than the next best option. You can't think your way through to which front-end-coding option at any given choice will bypass an irreconcilable combination of solutions later on. It comes with practice.
But that kind of practice should be kept open to anyone who can overcome the *lower knowledge-barrier* to front-end coding.
Creating -- fabricating -- barriers to everyone else, including dedicated front-end coders, from receiving that practice, to accommodate programmers, nurtures their control. But on its face, more control has nothing resembling a 1:1 relationship with greater success. It's wrong from every angle I look at it.
"I think as applications get more front-end intensive where the CSS / Javascript becomes a programming language in an of itself, it will definitely get much more challenging."
The highest-traffic sites look like craigslist, google, and yahoo. If Facebook could take a page from their book, I think no one would miss the front-loaded functionality, and everyone would prefer the faster-interaction better. "More challenging" sounds like an harbinger of mediocrity.
@Mike,
"I coded the first draft of 12-or-so ready-made website templates for a major hosting company, offered as part of their suite of comprehensive hosting services."
LOL!! Can I have your address so I can mail you a horn you can toot? ;)
"A good secretary knows more than the best front-end coder."
What is a front-end coder anyway?
"If I had coded the CSS the way Nicole Sullivan seems to be advocating, the number of people who could glance at the code and do ninja-backflips through it to customize it further would have gone from one to zero."
So who was the "one" that could have customized it the way you coded it?
I'm not sure what point you are trying to make in your comments, but it was great for a laugh! You have obviously a high regard for your abilities, and your philosophical word-smithing is really touching, really.
@Mike,
When you bring up Google, Yahoo, Craigslist, you actually make a really good point. For work, I definitely build things that are more Application than they are old-school website. As such, I think they, to some extend, need to be more complicated to provide a more meaningful experience. Although, if you look at something like GMail, you can still keep it simple while keeping it very powerful.
But, that said, when I was watching her presentation, I occasionally thought to myself - how would I do that in an application where every module needs to be creates for a specific purpose, optimized for a unique end?
I think perhaps there are things that don't apply to certain styles of development. But, that said, I still liked a lot of what she was saying and I think it can be applied on top of the more complex interfaces that an application would require.
[Abram] "LOL!! Can I have your address so I can mail you a horn you can toot?"
Why is ridiculing me for having an account of my own experiences second-nature to you?
What industry are you in that you don't know that it's the conventional practice for projects to go to the lowest bidder? What were you doing before 5 years ago?
[Me] "A good secretary knows more than the best front-end coder."
[Abram] "What is a front-end coder anyway?"
Someone responsible for the HTML, CSS, and JavaScript of a site. If you don't know what a front-end coder is, getting to know a good one will probably benefit you the most.
[Me] "If I had coded the CSS the way Nicole Sullivan seems to be advocating, the number of people who could glance at the code and do ninja-backflips through it to customize it further would have gone from one to zero."
[Abram] "So who was the "one" that could have customized it the way you coded it?"
I am the one who could have further customized my CSS casually.
[Abram] "I'm not sure what point you are trying to make in your comments, but it was great for a laugh!"
Thank you for confirming it's a wonder you feel the need to challenge anything I say.
[Ben] "...I still liked a lot of what she was saying and I think it can be applied on top of the more complex interfaces that an application would require."
Well, she didn't own everything she said, so sure.
@Mike,
Sorry to ruffle your feathers. I usually don't pick on egotistical people who tend to speak as if they know more than anyone else, and it was wrong of me to do so. I guess it's a Friday and I'm in a jolly mood. No hard feelings, eh? :)
Five years ago....hmm...good question. Heck, what was I doing 5 minutes ago?
Just curious, are you a designer?
"I usually don't pick on egotistical people who tend to speak as if they know more than anyone else..."
Yeah, don't be so sorry that the nitrogen in your lungs condenses into a liquid and enters your bloodstream, 'k? Because if it turns back into a gas when the shame subsides, I hear that's the most painful way to die.
I play something like tetris, and try to sell it as webpages for a living.
hi Brandon Hansen,
I just go through your website - http://lesscss.org/
but the way you created CSS codes are not validating in W3C CSS validation.
can you help to write less CSS coding with best validation.
please tell me a best way.
thank you,
ramesh
OOCSS takes some practice and discipline but, as I'm using it for my current project, I'll never approach another site without it.
I create 3-4 pages to begin with. One has all of my layout, one has all of my containers, one has all of my content styles, one has all of my form styles. Once I have created all of the elements on each of these pages, piecing a template together is like building a lego model.
When I am done I am confident that anybody, with simple understanding of html/css, will be able to create new templates without the hassle of unexpected content layout bugs.
And that's not tooting anybodies horn... That's how it should be. That's how all front-end developers should be thinking.