I was recently concerned how a professional web developer viewed classes in markup when discussing the validaty of using a .clearfix type class.
That line “this is how I want this styled” alarmed me somewhat, which followed my response of:
I stand by that but feel it needs to be elaborated a bit more and especially explain the “in a perfect world” comment.
“I want this element to”
The way I see things like
.clearfix in the same way that people used
<font> in the old days. It’s telling the element what it is and how to act. Granted that with CSS you don’t have to add such inline-styles to that element, but you are adding something that’s not semantic to the markup and thus bloating your code but also restricting the markup to a particular style somewhat. It doesn’t tell a human anything useful nor does it tell a machine reader anything useful, it’s only good for the specific CSS that uses
.clearfix. It’s the same as
<font> in some respect in that you are defining what something is doing without any real context;
<font> tells the text to look a particular way and
.clearfix tells it to look a particular way. I see very little differences in these two naming conventions except that at least
.clearfix doesn’t force the content to do something unless defined in the CSS where
<font> clearly does; but it’s still treating them the same.
The way to see CSS and HTML is simple; CSS is your style and design, HTML is your content and document. We want to separate that style as much as possible from our document hence why
<i> tags became redundant; as much as they where apart from the documents formatting like
<p>, they had very little meaning where
<em> had that meaning that we could also add a separate style too (though the HTML5 spec does try to bring a some semantics to them).
What About HTML Frameworks?
You may ask what I think about frameworks that use less semantic element for more design-based names such as the excellent 960.gs?
It does in fact break that rule of separating content and style by adding classes such as
.grid_4 to define the how the document should look. I cannot see any semantic value in giving a
<div> such a class so it’s broken for me.
Though I should say that it should stray people away from using such frameworks as if you aren’t worried about semantics then they are perfect and do the job really well; just that I feel they are semantically broken.
“this element is a”
Keeping in with my belief of content and style separation I believe that markup shouldn’t have unnecessary classes or IDs; they should have purpose and meaning so that a user can understand what it is, and that’s the key term here. When I write markup I want to say what items are if I need to such as
<div id="main">, straight away somebody can look at that and say “Ah that’s the main part of the site”. There’s a number of these that often have to be commonly used such as;
Just a few possible examples but all these are explaining what an element is. I can refer to these easily in the CSS to add a style suited to their needs. It’s a general name to a specific element; I’m telling the CSS what an element is and not telling the element what to do. As with any good markup, it should allow the person to write a new CSS file that will work with the markup without any changes to that markup (in a perfect world).
It Has a Flow
There’s an idea on a work flow appearing here that I know many front-end developers (who are all about the semantics at least) follow; content first, style later.
So what we will do here is develop our HTML first and put in all the content we want and then assign that content a value of what it is (if you’ve ever worked with XML, JSON or arrays and objects then you’ll understand what we are achieving here). So once you made your HTML doc with all the classes and/or IDs that define what certain tags are containing, you’ll then freeze that file and start working purely on the CSS; no changes to the HTML should be made once CSS work has started. I believe there are some companies that have people who are only allowed to work on CSS and not the HTML thus making a strong need of semantics in a doc.
Is it a Perfect World Though?
Unfortunately not; there are times when we need to add those none-semantic classes to make certain markup usable. The most popular culprits are
These little classes are typically used add a respective padding or a wrapper to get elements to act so. They do have a certain amount of semantics in that there name doesn’t suggest any strict styling elements, but at the end of the day they are used purely for style reasons (I wouldn’t have it if I could). It’s a nessary evil at times that I’ve not seen any push for a fix within CSS, but would be nice if there was one that didn’t involve some horrible workarounds; I’ve tried developing some and I still rather have none-semantic markup as they are messy and aren’t really bullet-proof.
Basically, it can all be summed up like so: tell your CSS what something is and not what you want something todo.
Update – 14/11/11 @ 1730
It appears that shortly after writing this blog post an opinion article was written on Smashing Magazine about the pointless pursuit of semantics. Now while I do talk more about the use of classes and IDs in this post rather than the document as a whole, I stand by the point that any semantics isn’t a pointless pursuit and thus wrote a comment in response to the Smashing Magazine article that can be found here.