A lot of conversation has happened in the past few months (that I'm aware of) regarding applying OOP principles to CSS. Well, it's called OOP CSS. I'm not really sure if we're actually dealing with the technique is truely object oriented, but the result is close enough for those that have been bandying about the term.
What is OOP CSS? I'll let the amazing Nicole Sullivan tell you in her Web Directions North presentation here, which I had the fortune of attending in the flesh (or meatspace, if you will. Do we still call it that?) If you're too pressed on time to watch through the presentation, then shame on you. However I'll offer a crude explanation: OOP CSS is making "modular" classes of CSS rules that take advantage of the ability to apply multiple classes to an element.
For more info, you should take the time to check out Jeff Croft's take on the subject here. In particular, check out the many comments.
This methodology can allow for some great reusability with CSS rules, with the intended result of reducing your stylesheet size. As an example that sprung out of Jeff's post's many comments, you could have elements representing success or error messages on a page that share the "message" class (with, perhaps, styles to help present a popup box-like appearance), but they also each have their own specific second class to help them gain unique styling traits, with the error message having the "error" class and the success message having the "success" class. This helps reduce duplicate styles, because both types of elements get the common "message" styles with them being defined only once in the CSS, with only the unique styles being declared separately.
So what's the problem with this technique? That's actually a question that's bound to open a fistfight of spaghetti western proportions among designers thanks to the strongly held opinions about semantic versus presentational markup, the futility of trying to mimic programming techniques with CSS, etc. But from my viewpoint, it's a good tool for helping simplify stylesheets, by which we save our clients money, which makes us more competitive in giving them more for their dollar, which is a must-have trait in this current economic climate.
But there is a major problem that we all need to be careful about, despite my approval. What is it? What possible blemish could exist?
Think hard. It's the Internet. What possibly could ruin any good thing on the Internet?
That's right. It's the undead shadow of life-stealing hunger that constantly radiates from Redmond. Despite having driven several silver stakes through its chest, even its own creator has been incapable of putting the dark beast to sleep. I speak, of course, of Internet Explorer 6.
I have another, shorter, four letter name that I like to call it. I've been informed by my employers that I cannot use that word on this blog. So instead I'll call it Carl, Black Beast of the Filthiest Bog.
Carl is a jerk. Or perhaps Carl huffed paint in high school and now simply doesn't know any better. Let this be a lesson to you kids, huffing paint will not make you into a good web browser. (Cue NBC's "The More You Know" Theme.) In relation to this problem, Carl has a really bad defect. Carl screws up when trying to render styles that are applied via multiple element declarations.
What do I mean by that?
Let's say you've got elements with the following class combinations: "error message", "success message", "error button". You create a style that applies to messages, but you want to create a style that also applies to just error messages (but not error boxes). What would you use as your rule descriptor?
If you said ".error.message" or ".message.error", you've been paying some attention in class. However, you've got a problem when it comes to IE6 rendering these styles. IE6 is only capable in these types of declarations of reading the last class in the descriptor. So the first example would apply (in IE6) to all "message" elements, and in the latter it'd be all "error" messages. This quickly makes things difficult for OOP CSS if you're not extremely careful in how you name your elements and what styles you give to what rules.
Having a hard time believing me? Please take a look at this test page, which uses lists as a simple example. View it in any average browser, then pull out your dusty system from the dark ages and take a look at it with IE6. You'll notice a slight problem with the list-item numeral markers on one of the lists.
What do we do about this? There's a number of options. As much as I'd like to say "screw IE6" and just ignore it, that's not going to work unless the site you're building simply doesn't get IE6 visitors (which seems unlikely considering it's market share). You can also take an approach like Andy Clarke proposes with his Universal IE6 CSS and serve IE6 a generic stylesheet to make it look clean and simple rather than feeding it the styles that the other browsers will receive. Or you can think out your class names with great care and make sure to arrange your styles with utmost care to prevent the need to refer to a group of styles with a mutli-class descriptor...
What you can't do is go willy nilly and ignore the problem, or you'll lose any cost savings you gained with the OOP CSS techniques in the first place as you revisit IE6 again and again to make the page usable for people stuck on that doddering malcontent of a browser.
Multiclass descriptors. Carl. Mortal enemies. Keep them apart if you want a clean site.
