Recently an interesting discussion occurred at Sweclockers regarding the semantics of HTML classes. I argued that classes in HTML should hold significant semantic meaning, and was surprised to find that many disagreed. It started when the following piece of code was posted as a suggested solution to the original thread problem:

Apparently, many people don't see any problems with this piece of code. I did, however, and replied suggesting that this was very bad practice and that the white class is completely non-semantic and that this isn't what classes are for. This caused a minor outrage, and other users claimed, among other things, that classes can't affect semantics. This is something I completely disagree with. On the contrary, classes provide a great amount of semantics and thus must be named properly. Consider the following example:

Something went horribly wrong.

The class red may describe exactly how this error message will look, but it is semantically useless. What do I gain from knowing that this paragraph should be red? Nothing. If we decide to name this class error instead, we immediately realize (no matter what text the paragraph contains) that this is an error message. This is especially useful for robots and HTML parsers, because it simplifies the search for specific elements.

Up to this point most of the other posters in the thread agreed with me, but still claimed that this wasn't semantics. They referred to the semantic difference of i and em and the definition of those in the HTML specifications, and proceeded to claim that classes cannot give content a semantic meaning, because they aren't defined to do so. That's when it struck me; this was so hard to understand because classes don't have a clearly defined semantic meaning.

The fact that their semantic isn't clearly (or even uniquely) defined doesn't mean they don't have any semantic properties. Classes are there to abstract the element in question. They should describe what the element is, what it's there for, not how it should look. That's what CSS is for. This is semantics. Just like in HTML.

In HTML we have clearly defined elements with semantic properties. We have p, which semantically means that we want a paragraph. We have em, which signifies we want to emphasize something. But what if we have different kinds of paragraphs, for example? Maybe we want a paragraph describing an error? Great, we'll add the class error! The element is now not only a paragraph, but it's an error paragraph. Semantics in HTML and CSS is the exact same thing. The difficulty here seems to be to realize that even if it is a loosely defined "fuzzy" semantic, it still is semantics, and we have to know this and give our classes semantic, meaningful names. It improves our code the same way using semantic HTML does. It's just a little more subtle.