I found the HTML and CSS to be pretty gruesome (no grids, px-specified font sizes, etc.), but for my requirements (looks good, can be plugged into a Rails app with minimal trouble, has a template page with a sidebar) it was more than sufficient.
I ended up redesigning my site's semantic structure last month (moving it onto Blueprint CSS), which necessitated re-writing all of the CSS, but it was still worth it as the theme gave me a solid look and feel to mimic.
Using CSS frameworks is much worse than using px for fonts (unless you care about really old versions of IE). Any CSS framework will litter your markup with purely presentational classes.
I should clarify: I have a handful of Sass mixins that are based upon the Blueprint CSS grid system that I use to define a grid-based layout for my websites. There's nothing presentational anywhere in the Haml.
I don't particularly care about older versions of IE, but some of my clients definitely do.
Another useful aspect to employing Blueprint (I can't speak for 960gs or others) is that it drastically curtails the amount of work I need to do to ensure that my presentation doesn't break in Gecko, Webkit or Trident. I've seen plenty of edge cases (unfortunately, none that I can cite off the top of my head) where Webkit and Gecko work very differently, and using Blueprint smooths those over.
That is an argument against naming in general. 'When one day you will find that your class="product" contains contact information, you might now the part of the answer.'
I found the HTML and CSS to be pretty gruesome (no grids, px-specified font sizes, etc.), but for my requirements (looks good, can be plugged into a Rails app with minimal trouble, has a template page with a sidebar) it was more than sufficient.
I ended up redesigning my site's semantic structure last month (moving it onto Blueprint CSS), which necessitated re-writing all of the CSS, but it was still worth it as the theme gave me a solid look and feel to mimic.