At What Point Do Semantics Not Apply?

There was a large response to the article I posted a couple weeks ago, Please Do Not Use CSS Frameworks, which for the most part was evenly divided. There are many people who support and stand behind both the creation and implementation of CSS frameworks. They truly see the benefit in saving time in development as well as having a more structured environment in which to work.

I can absolutely see the benefit to a CSS framework in that regard, and I think that’s where my sensational title of a couple weeks ago skewed the tone of the entire article. Some readers (understandably) felt that I saw absolutely no worth in a project such as a CSS framework. That’s not the case, entirely. I simply see some issues that could be counteractive, and those issues can [usually] be applied to nearly any framework in existence.

Frameworks are a fantastic idea, fantastic, but I’m sure we can all agree that there is an extremely high potential for ‘learning the framework’ as opposed to learning the language itself. This is a major issue to keep in mind, especially with something like CSS. One of the other issues I’ve got with the implementation of a CSS framework is semantics.

Semantics and CSS? Applicable?

The resulting discussion surrounding the release of Blueprint itself has been utterly fantastic. Many great minds have left opinions on the release. The pros, the cons, the ridiculousness surrounding the reaction of such a release. I’ve tried to read as much as I can of this conversation, and some interesting ideas and thoughts have come up.

One of the more interesting points brought up was that surrounding the semantics of class and id names. While I feel that semantic value can be given to a class or id, other developers thought it was simply ridiculous, that they are there to act [more-or-less] as hooks for CSS and JavaScript. Others felt that the classes and ids used in Blueprint are applicable because values such as .prepend-8, .pull-2, and .span-22 were spot on in their use.

My stance is the following: if a class or id can be given a more descriptive value, why not? While some developers feel that it is the markup which needs to be semantic, I can see a value in trying to create more semantic classes and ids. Microformats are a prime example. Microformats may not use values which are initially obvious to their meaning, but their objective is such. Microformats use classes in an effort to better define data in a semantic way. Why not try to carry this over to the rest of your document?

From what I can gather, it seems as though some developers feel that trying to create a semantic class or id is just silly. What do you think? Is a class little more than a hook for CSS to apply some style?

Are semantics applicable with only an associated meaning?

Microformats make sense to those who have worked with them before. Each class has a meaning because there is a large set of documentation to back it up. Without that documentation, would the class still be semantic? This same issue carries over to Blueprint. At first glance, the classes used are awkward and seemingly meaningless — until you read the documentation. Is it at that point they obtain semantic value?

I think to those who have come to accept and use Blueprint on their projects, there is a resounding yes. This concept (and reaction) is closely related to Microformats; some people agree, others don’t. If you’re familiar with the framework, Blueprint has attempted to keep class names partially semantic.

So, what’s the problem?

While the classes within Blueprint attempt to retain semantics when taking the entire framework into consideration, it does so only to provide meaning for the visual elements involved. It is literally impossible for Blueprint to take into account the actual information presented. I think this is where the issues regarding semantics come into play.

Is there a divide when taking into consideration the semantics of (X)HTML versus the semantics of classes? Are they one in the same? (X)HTML has a set of defined tags, each of which inherits a meaning. CSS is different entirely, allowing the author to define much of which comprises a completed stylesheet. It is up to the author to understand a meaning applied to any class or id he chooses. Can semantics still be applied? In my opinion, yes they can. When I’ve got a project in front of me, I’ll try to best define the provided information using meaningful classes and ids not only to help me remain more organized, but also in an attempt to help others on my team get up to speed quickly when working with my markup and style.

I’m really quite curious to hear how others feel about this ‘situation’. Are semantics completely inapplicable when it comes to CSS? Do you feel as though trying to create semantic classes is simply overzealous? Without the structured definition and documentation of (X)HTML to back it up, is CSS better left to be implemented on a ‘what works’ basis? Are semantic names that only describe visual orientation as meaningful as valuable as those which describe the informational meaning? Do you feel this topic is just beating a dead horse? Please, provide your opinion.