Rob Dodson talks internets

I want to work on a code generation tool, similar to the one offered up by Rails. However my Ruby-fu is a bit rusty at the moment so this might be an interesting struggle.

This is a quick post just to scratch one of my own itches. I’ve been using Octopress every single day for around two months now and the generation time for my blog is slowly starting to creep up. I’d heard that you could isolate a post and just preview/generate it instead of doing the whole blog every time but it wasn’t until today that I finally decided to look into it.

Yesterday I introduced SMACSS and did my best to give a high level overview of its main ideas. I’m using it on my current project and I’m really enjoying it so far. There’s just something about having things codified by someone with more experience that gives me immense comfort. When I feel confused I can refer back to those docs and sort out what would be the best path. Standing on the shoulders of giants and all that jazz ;)

Today I want to talk about a CSS framework called Foundation, written by the team at ZURB. Unlike SMACSS, Foundation is an actual library of modular code ready to help you quickly prototype your project. The two aren’t mutually exclusive. You might think of Foundation as a shiny new toolbox but SMACSS is going to be your ‘How To’ manual, helping you implement all the new goodes that Foundation has to offer.

In an effort to further my understanding of CSS best practices I’ve ended up with two sort of looming frameworks: OOCSS and SMACSS. After reading up on both I feel more drawn toward SMACSS, most likely because it features a lumberjack on its site. I want to give a quick summary of what SMACSS has to offer. In so doing I’m going to borrow liberally from the documentation and then explain my thinking as it relates to certain passages. Cool? OK.

CSS is, for me, one of the most challenging and nerve wracking aspects of my job. With most programming languages there are frameworks and guides and heuristics that all make up a suite of best practices. CSS doesn’t really have anything like this and as a result it’s kind of a mish-mash of good rules to follow, definite don’ts, and lots and lots of grey area. Since I’m starting a new CSS heavy project, and because I want to further my own understanding in this realm, I’m going to spend a few posts exploring the topic of what makes good, maintainable CSS. Along the way I’m also going to point out a few frameworks that I’ve been looking at, in particular OOCSS and SMACSS. But lets kick things off with a discussion of what it means to write good, semantic CSS selectors and we’ll follow up with frameworks in our next post.

Today’s the day we wrap up our countdown timer and deploy it to Heroku. But before we launch this puppy we need to clean house a little and spice up the visual appeal.