Beast-Blog.com
Class & ID Naming Conventions

First of all I will state that I had this article in my drafts, started with a single line: “What’s in a name?” I was going to offer something I felt was logical topic of conversation regarding naming classes and IDs for what they are so as to remember them and so they would make sense to you and your client. However, between then and now I had an unintentional but highly valuable discussion with some fellow Web Standards Group members. The topic will remain the same, but the advice I’m going to offer has been altered. I’m thankful I got the information I did before writing and publishing this article because I can now offer a more well-round article. The reason is some of the advice I was going to offer would have been a bit off mark and possibly misleading and I want nothing more than to offer solid information here. I was going to tell you that a logical class name for, say bold text (not to be confused with emphatic text using the <strong> element), would be .bold. I was wrong on some levels. While on the surface it may seem like a logical choice, it’s maybe not the best choice. I now realize it’s often best to name style classes not to define the style, but rather to be indicative of the function of the style. Why is it styled this way?

Bold is a rather difficult one to wrap one’s brain around — it was for me — because the function may be to show emphasis. It teeters on the edge and may be more difficult to define its function. In other words why would something be bold? Shouldn’t it be to show emphasis, or maybe a heading would be best if it’ll be used to lead a topic and not be shown in-line (even though headings can be styled to be displayed inline). You should not use a heading to make bold text, as stated in the WCAG, so this can be a tricky one I’ll let you answer for yourself. I want this to be easy to understand so I’m going to offer and discuss some easier-to-define class and/or ID names in this article. While they should still make sense, be logically named, be as short as possible, and if at all possible universally mean something. The class .bold is a tough judgment call.

Class and ID Examples

Instead I’ll use some others; the first being a class name for some red text. The first question to have to ask yourself as a developer, though, is why do you want red text? And I warn you, this one can be difficult one as well. If you answer that you want red text as a highlight color, you might want to ask why you’re highlighting text. Is it to convey emphasis? If so, you may again want to use an emphatic element like <strong> or <em>, for strong or light emphasis, respectively — and you can style these elements red by the way. If you answer that you want red text to have another meaning, like color-coding, again you must think again, unless it’s purely a stylish thing because you have red highlights on your site. But you don’t want to use a color solely to convey meaning, again, as stated in the WCAG, as not everyone will see the color for any number of reasons, not just color-blindness. But you can use color to help convey meaning. Now were getting close to a good answer: Let’s say you tell me want to use red to display error text (it does have a universal association). Now we’re on the right track. Let’s call the class used for this red text not .red, though, but rather let’s call it .error. But we’re not done. To account for those who won’t see the color red, we want to make sure the content says it all. Remember, our red-colored text is going to help convey the idea. We better use the word “error” in the message. Since it’ll be a pronounced message and probably followed by an error message, we may opt to use a heading.

Using error for this class name defines its function. And the good news is you can change it down the road to a different color should you decide to restyle your site. Let’s say you want to use yellow. Having yellow text with a “red” class name would be kind of silly and misleading. Whereas it’ll always be an error. Want to see a working example? Submit my contact form with the required fields left empty.

Okay, let’s investigate another example. This time I’ll offer an ID. Let’s say you have an unordered list <ul> you want to use for your navigation. In such a case you might want to give the list the ID name #navigation or shorter, #nav. And you’d be right in doing so. But let me throw you a curve ball. Let’s say you have more than one navigation menu. Let’s say you have three navigation menus: one at the top of the page for help links like skip links, site map, etc., one on a sidebar for your main navigation menu, and the final one at the bottom of the page for things like a jump to “top” or “copyright,” etc. That’s easy to solve, right? Just call them #topNav, #sideNav, and #footerNav, right? Wrong… partially anyway. What happens if you want to restyle your site and change their locations. Granted this may be unrealistic because the skip links will likely stay at the top of the page as they will be in the underlying code as well so #topNav is quite apt. Same goes for the #footerNav and its “top” link and whatnot. That’s where it’s going to be in the underlying mark-up so it, too, is aptly named. But what about the side navigation menu. Will it always be to the side? What if you restyle your site and decide to place it under the masthead? Now things will begin to get a little messy. Better come up with a name that better states it’s function, not its location. Let’s call it #mainNav.

Splitting Hairs?

Is this a bit of hair splitting? You may think so. I did. I want my classes and IDs to be logically named, and arguably this is beneficial to the client and others who may have to deal with said classes and IDs down the road. But there is a such thing as a more logical logic and to a point this thinking exemplifies that. But like all things, a great deal of thinking has to be put into it so to avoid crossing the narrow divide between semantics and a lack of common sense. The examples above are pretty solid and undeniable, but what about embedded image classes that define position as just one example. Regarding image styles I’d normally use the class names — not IDs because IDs can only be used once per page whereas classes may appear in multiple instances on a page — .left, .right, and .center. That was going to be part of this article originally. These names will obviously be good for the client. But, after getting input from others, I have to ask what if you change the site and want to reposition your embedded images? Would you end up with .left-class images being floated to the right and .right-class images being floated to the left? Or what if you no longer want to center your .center-class images? A more generic, and some will say more semantic alternative could be devised. Say, for example: img.posA (for left, at this time), img.posB (for right), and img.posC (for center). There are two sides to this coin: Semantic versus uninhibited common-sense. But both arguments have some merit.

Do As I Say, Not As I Do

The heading above is a rather old saying used by parents when talking to their kids. They use this (or at least think it) because over the years they have learned from their mistakes yet are too set in their ways to change themselves; smokers will tell their children not to smoke. On this blog, being I was a rank amateur when it was started, positions its images using inline styles. I’m wrong in doing this, but I still do it because I started it this way and have chosen to be consistent and continue with this method. My thinking at the time was the embedded image isn’t part of the site but rather part of the content. In fact, the decorative supporting image which appears on most posts belongs to the post itself and is positioned relative to its parent — the first paragraph in this case. At the time my concern was that since it’s part of the content I wanted it to be portable if taken off the site. For example, if you look at this content by way of the only moderately styled Feedburner feed page you’ll see the images are still floated. Perhaps this isn’t a terrible thing and some will even like that. My logic seemed sound to me at the time; hey, it looks nicer… to me that is. But some users don’t want any styling in their RSS feeds. To some this is their primary method of getting away from styles and thus giving them control of my content. By using inline styles I override this and I am admittedly wrong in doing so. Because I do this the only method of them taking back styles is to remove CSS support altogether by way of their browser or by way of applying their own style sheet. But this is getting off-topic. I should have applied a class to these images but I didn’t know better at the time. Now I may be really screwed if I decide to make a change. In this case, using img.left, img.right, and img.center would have been a lot better.

Back on Topic — More Examples

So what are some other examples of perhaps poorly named yet seemingly intuitive and innocuous classes and IDs? Let me give you some along with some alternatives. Are these examples right or wrong, or black and white? No! But they are food-for-thought. Take them how you like.

ID: #sidebar

A growing trend lately is to place what would normally be “sidebar” content under the main content. In light of this, perhaps “sidebar” isn’t the best choice. How about calling the old sidebar <div> #supporting, #subContent, or #misc?

IDs: #leftCol, #rightCol

What happens if you swap these? #leftCol moves right, #rightCol goes left. Messy. How about using #col1 and #col2 instead, following the numeric order of how they appear in the source code. Even at 100% width they can still be called a column.

CLASS: Italic

During the conception of this article I was going to offer this one as an example when styling some text as a person’s thought (not to be confused with emphasis). Even though I firmly believe this might actually be a solid case for using the <i> element because it is actually part of the content’s meaning and more than just a style, just like writing Latin names; it’s an accepted written standard that was around long before the web was even a notion (but that’s a topic for another day). I will say now, though, if using an italic style to convey thought, then thought is the function and perhaps the best way to style it would be to use a .thought class instead of a class called .italic. A problem does come to the surface when applying emphasis within a thought, thus a .thought em or .normal class might be needed, but this, too, is another topic altogether.

ID: #center

I’ve seen this one used to describe the center column or main content <div>. This one would probably be better off called — as most already do — #content, or even #main. The latter describes the function of the <div> where as the former describes the position, which, over time, may change.

A Logical Middle Ground?

I must issue a warning that even though while I agree with this thinking, typical of my web methodologies I reside somewhere in the middle ground between pure semantics and good old fashioned common-sense. Ask yourself some questions. Your answers will clarify the direction best suited for you. If you’re making a site for a client, will the client be updating the site and using certain classes? If so, are you prepared to write a tutorial on what classes do what because the class and ID names you’ve chosen are less clear than they need to be? Are best practices the wisest choice over convenience-based logic? Who are you trying to satisfy? Are you doing it for the World Wide Web Consortium? Will you or your client be doing a CSS re-boot or re-styling every year or two? If not, is it a good idea to ditch the use such class names as .left or .right? Is it worth it to potentially spend hours coming up with class names based on semantics alone — even though once determined many can be re-used — when coming up with a simple says-all class name may work better for some users? And if you choose not to, aside from the potential re-styling of your or your client’s site, are there any penalties or drawbacks to usability and accessibility?

More Examples Needed!

To help solidify and clarify the message, I need your help. Please respond to this post with other ill-named classes and ID examples and what semantic alternative you think should be used. I don’t expect everyone will agree with them, and some good cases can be made against some of this (like the image position classes being good for client comprehension), but I am having hard time coming up with good examples. I also want to hear the other side of this. All opinions have merit, whether they be for or against. Standards are terrific, but if they start getting in the way of getting the job done it may be time to take a step back. I doubt I’ll ever be called a standards purist, but I’m okay with standards realist.

Filed under Coding & Markup, Do It CSS Style —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:

The Joys of Consistent Web Practices »

The Best of the Beast in 2006 »

Better SEO through Blog Post Titles »