It would be great if you could take a few minutes to elaborate with another comment on the site to ensure anyone who happens to read it knows more about why you feel the way you do.

Thanks again for your well-versed reply!

You can still have semantic classes or ids when using a framework in my opinion. Have a look at the following examples:

#content isn’t a Blueprint id. Do you know what that holds?

#modules and .module are mine also. Which side are they on?
.colour-2 is mine, isn’t for semantics, serves purely for colour-scheme switching.

I used the framework initially, then afterwards added #logo, #header, #footer, #nav, etc. Does the fact that I used a framework make my document any less semantic than yours, now that I have added semantics?

When frameworks are used to produce non-semantic documents in the hands of the novice, who’s at fault? The framework or the novice, the tool or the user?

I’ll leave you to make up your own minds, but I know that the next time I try to hammer two bits of wood together and the wood splits, I am not going to be throwing my hammer away.

So I agree with you in the point that there’s semantic on CSS and we have to make a good use of it.

@Simon Martin: I tend to agree with what you’re saying, I too take a minute to think about what it’s going to be like when I have to make an update on a current project a year from now; is it going to be easy to resume where I left off?

@Jason: Yes I definitely agree, I try to use effective class values for exactly that reason.

@Roman Bercot: Microformats definitely aim to make up for the shortcomings of (X)HTML, but couldn’t you view effective class names as doing that very same thing? You’re absolutely right in saying that many companies could really care less about this type of issue, it’s hard enough to convince them to work with a reputable agency as opposed to having the boss’ son whip something up in Dreamweaver over the weekend.

@Riddle: At first, the idea of using names such as those you had mentioned didn’t make sense to me either. But if you’ve read the documentation behind the reasoning for the naming, it begins to fit together. That’s where the issue arose for me; if there is documentation to back up their use, is it okay to use such names? In the end, I do feel that using meaningful names is more beneficial in the long run.

@Ian Gordon: You’re absolutely right; it would be very rare (and surprising) that a developer would take the time to remove all the extra bloat left over from implementing something like Blueprint, or another CSS framework. While we’re only talking about a couple k here and there, it’s just not needed. The attractiveness of something like Blueprint is absolutely the speed at which you’re able to get up and rolling on a project.

@James: I think every developer has at least a bit of code they use to start every project. I’ve got a very basic folder structure that I use which has a few files in place to get me going, but it’s nowhere near the size and depth of something like Blueprint. Many people see Blueprint as something of a full golf bag, with each club ready to be used in whatever way you wish. While it can be a great thing for one person, it’s just a hurdle for another.

@zack: Stating that developers using class names that you or I feel are less than ideal is wrong isn’t necessarily the way to go about it in my opinion. Many developers have been using namespaces they’ve come up with over their entire career. The names make perfect sense to them and their team and really help everyone stay on the same page. That is one of the major points going for Blueprint, it allows for each developer using it to know exactly what’s going on before comparing the markup to the style. I completely sympathize with your desire to see some CSS3 action :)

@David Eglin: Very well written. From what you’ve said it sounds like we stand in the same spot when it comes to an issue such as this. While the Blueprint documentation can help everyone stay on the same page, meaningful identifiers can do that as well. I would like to agree with you in that a CSS framework can definitely help with initial development, but how will it fare when it comes to making significant updates later on? It will be great to read future articles detailing a comparison between working with a CSS framework and not.

@Robert Bercot: I agree, I don’t think an assumption of a lack of skill is a point to touch upon. You’re right, the implementation of CSS3 is a long time coming, and will continue to be a tease once browsers actually implement. We’ll be dealing with the same issues when it comes to HTML5 and any new tags that come with it; how long until we can effectively use them?

Thanks to everyone for taking the time to write these well-thought reactions. Reading the opinions of others really helps to get a better view of the overall situation, and I thank everyone for taking the time out of your day to leave your thoughts.

Zack makes a good point that the specifications should alleviate the need for some of these things. But how much progress has really been made there? Every browser on the market could implement full CSS3 and HTML5 tomorrow, but my users would still be running IE6.

These frameworks completely disregard the separation, re-introducing presentational markup into the mix. This, in turn, leads to problems of maintainability – A year down the line, when you want to re-design the website, if you have written your code semantically, all you have to do is mess around with your css. Using a framework such as Blueprint, you need to dig around in your html markup, which really shouldnt be necessary, as you’re not looking to change your content, just the way it is presented to the user.

As mentioned above, there is also the issue of teamworking to consider, too. Using semantic markup, a fellow team member can easily go into a page, and make an instant and intuitive link between a container element, and the content it holds. Using frameworks to build your pages, all you have to go on are presentational classes – “col span-12″ etc.

Yes, the use of a framework can speed up inital development time, but I think that any benefits gained in the early stage will be cancelled out by the extra time and effort taken to produce updates. There is, as rightly mentioned above, the issue of people learning the tool, not the technique.