OOCSS & Modular CSS Lightening Talk
Last month, I was invited to give a lightening talk for our local JavaScript meetup group, SEM.js, at their 1-year anniversary celebration. They wanted to switch things up a bit, so the topics were on a wide range of things mostly unrelated to JavaScript. They asked me to discuss OOCSS. And so, in under 8 minutes, that is what I did.
Let me tell you, that was a rush. I thought I was going to have a heart attack, knowing I had to semi-thoroughly explain OOCSS, which of course also meant explaining modularity in general, in under 7-8 minutes. But I made it, and apparently came off as fairly calm, and so I decided to do it again at GDI Detroit & Vitamin T’s Digital Rendezvous.
The Digital Rendezvous event was held in a brewery, so I prepared for my talk with the help of an IPA. I also had a little bit more time to present, so was able to get in a bit more explanation. Overall, better than the first time, but sorry – no video.
At this point, I’m entertaining the idea of starting up a regular lightening talk+beer event around Ann Arbor. This may be a GDI event, or something entirely separate, or maybe a collaboration! In any case, I’m excited!
2 Comments | Post a comment
I love the frankness in your slides (“shrugs”)!
A question in passing, I think there are some fundamental issues with OOCSS. However, I wonder about the experiences of other web developers; it seems you see advantages in working with it, but does it outweigh the cons, if you’ve observed any?
@Jens – The only “cons” I’ve really seen are issues with classitis, but those are only actual issues if you have a problem with classitis. The whole presentational vs. semantic naming debate kind of ultimately comes down to personal and team preference. If you/the team is against presentational naming, then you might want to lean more on methodologies like SMACSS or Atomic Design – both of which are still based on OOCSS and the concept of objects – just at varying scales. If you’re ok with presentational naming then pure OOCSS might be a comfortable way to go.
Personally, and I think this is probably pretty common, I use a hybrid system – creating reusable, presentational objects along with larger, semantic modules. This gives me the flexibility I need on a large-scale site with many design variations.
I read your post and one thing I’d like to address is your comment on the critical use of IDs and descendant selectors. I would argue that these were previously an important part of the cascade and frontend development, but the concepts that OOCSS introduced began to make it clear that avoiding those methodologies will result in far more flexibility, scalability, and maintainability.