How To Compose HTML ID and Class Names like a Rockstar

As you know, both id and class values can be used to provide implementation hooks for presentational (CSS) and behavioral (JavaScript) effects in front-end code. Of course, they can also affect semantics; microformats are a design pattern that makes heavy use of the class attribute in a specific way. But do you know what else these two core attributes can, and I argue should, be used to do?

I think, when crafted thoughtfully, id and class attributes can also improve our code’s organization, readability, and can directly improve many aspects of developer-to-developer communication, which can be particularly important on large teams. Indeed, part of the success of microformats came from creating thoughtful conventions about which class names to use when, and why.

ID and Class Name Considerations

When composing values for id and class attributes, I ask myself the following questions, in order, to help guide me towards a good (and reproducible) name:

1. What function does the element serve? (Why’s it there? What’s its purpose?)
2. Are there other elements that serve similar functions? (How similar? What are the differences between them?)
3. Are there other websites that use elements for the same purposes? (What are those named?)

Answering the first question helps me produce self-documenting code by coming up with a name that matches the code’s function and purpose. For instance, one glance at code like this immediately suggests that it’s a navigation list, so having a reference to “navigation” in its name makes obvious sense.

<ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about/">About</a></li>
    ...
</ul>

Answering the second question helps illuminate opportunities for reuse. For example, unless there is only one navigation element in the entire codebase, identifying the above code merely by function (“navigation”) is unlikely to be sufficiently distinguished. It might therefore get named “main navigation,” “site navigation,” “navigation bar,” “global navigation,” or some combination of these, while another navigation element gets one of the other names. Let’s go with the “site” name for the sake of this example:

<ul id="sitenavigation">
    <li><a href="/">Home</a></li>
    <li><a href="/about/">About</a></li>
    ...
</ul>

Answering the third question can help code interoperate technically (as in the case of using Microformats), but it can also help keep naming schemes themselves clear and simple. “Nav” is a common abbreviation, and is even a first-class HTML5 element in its own right you can use today. By taking inspiration from existing work, you lessen the cognitive effort needed to make and maintain your own conventions.

<ul id="sitenav">
    <li><a href="/">Home</a></li>
    <li><a href="/about/">About</a></li>
    ...
</ul>

The Importance of Naming Conventions

A naming convention is simply an agreement among developers to use the same kind of name to refer to the same or similar things, and a different pattern to refer to something else. Such agreements are incredibly simple, but incredibly powerful. For example, I bet you can read the following sentence because English lettering follows widely agreed upon rules: I re_lly l_ve sem__tic __rkup!

Conventions enable anyone who’s familiar with their general principles to fill in the details even when those details are missing. The innate human ability to extrapolate information based on conventions and prior knowledge isn’t just useful when it comes to filling in the blanks. The same technique can be used as a way to communicate purposes and intentions.

For elements that are generic to most websites, such as global navigation lists and search fields, I use TitleCase names. For elements that are specific to one site, however, I use lower-case-dashed names. I’m using the naming convention as a kind of microsyntax to imply “generic” (aka “global”) versus “specific” (aka “local”) scope regarding the purpose of the element, a distinction that can help orient fellow developers within a big picture view of the codebase.

Following this convention, sitenav becomes SiteNav:

<ul id="SiteNav">
    <li><a href="/">Home</a></li>
    <li><a href="/about/">About</a></li>
    ...
</ul>

Note that the use of TitleCase versus lower-case-dashed names are independent of whether or not they’re present in a CSS class or an id attribute value. Here’s how I might mark up a text input field in a search form:

<input type="text" class="SearchField" id="widgetco-search" title="Find a Widget" value="" />

We know that a “search field” is a generic concept so, according to my conventions, it gets TitleCased. By the same (obvious) token, Widget, Co.’s specific search field doesn’t exist on other websites, so it gets a lower-case-dashed name. Among my 5 top tips for beautiful markup is use markup patterns consistently; extending this concept to id and class values is a natural evolution.

From Convention to Common Code

Ultimately, the naming convention you choose doesn’t matter as much as sticking to it does. However, obvious conventions are easier to pick up quickly, so one way to test your name is to try speaking your code aloud as though it were English. Does the grammar of the name you chose make sense when you hear it, or does it sound awkward?

Consider the form field. In English, it might read: “The widgetco-search text input is a SearchField. It lets you Find a Widget.” This makes grammatical sense, and both the class attribute’s “is a” relationship, as well as the id attributes “the” designation is made clear.

More to the point, you already know that an element with a class of Skyscraper is probably going to be using relatively widespread and standard presentations and behaviors (and indeed, a Skyscraper is an IAB standard web advertisement format), while an element with a class of wonderful-sale probably isn’t. And since you know this instantly, you can more confidently segregate your custom code from reusable reusable components in an organic way.