How To Compose HTML ID and Class Names like a Rockstar

Share this article

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.

Frequently Asked Questions (FAQs) on Composing HTML ID and Class Names

What are the best practices for naming HTML IDs and classes?

When naming HTML IDs and classes, it’s crucial to follow best practices to ensure your code is clean, readable, and maintainable. Firstly, use descriptive names that reflect the purpose or function of the element. For example, instead of naming a class ‘blue’, name it ‘header’ if it’s used for the header. Secondly, use hyphens to separate words in a name, as this improves readability. For example, ‘main-content’ is easier to read than ‘maincontent’. Lastly, avoid using IDs and classes that start with a number, as this can cause issues in some browsers.

How can I avoid conflicts between HTML IDs and classes?

To avoid conflicts between HTML IDs and classes, it’s important to remember that IDs must be unique within a document, while classes can be reused. Therefore, use IDs for elements that appear only once on a page, like ‘header’ or ‘footer’, and use classes for elements that are repeated, like ‘button’ or ‘list-item’. Also, avoid using the same name for an ID and a class to prevent confusion and potential styling issues.

Can I use special characters in HTML IDs and classes?

While it’s technically possible to use special characters in HTML IDs and classes, it’s generally not recommended. Special characters can cause issues with CSS and JavaScript, and they can make your code harder to read and maintain. Stick to alphanumeric characters and hyphens for the best results.

How should I handle naming conventions in a large project?

In a large project, maintaining consistent and meaningful naming conventions for HTML IDs and classes is crucial. Consider using a methodology like BEM (Block, Element, Modifier) or SMACSS (Scalable and Modular Architecture for CSS). These methodologies provide guidelines for naming and organizing your CSS to make it more scalable and maintainable.

What’s the difference between using hyphens and underscores in HTML IDs and classes?

Both hyphens and underscores can be used in HTML IDs and classes, but they have different implications. Hyphens are typically used to separate words in a name, making them easier to read. On the other hand, underscores are often used in programming languages to denote a private variable or method. Therefore, using underscores in HTML IDs and classes might confuse other developers who are used to this convention.

How can I make my HTML IDs and classes more semantic?

Making your HTML IDs and classes more semantic involves choosing names that reflect the purpose or function of the element, rather than its appearance. For example, instead of naming a class ‘red’, name it ‘error’ if it’s used to highlight error messages. This makes your code more understandable and maintainable, and it also improves accessibility.

Can I use CSS selectors in HTML IDs and classes?

Yes, you can use CSS selectors in HTML IDs and classes to target specific elements for styling. However, remember that IDs have a higher specificity than classes, so styles applied to an ID will override styles applied to a class. Also, avoid overusing IDs, as this can make your CSS less flexible and harder to maintain.

What are some common mistakes to avoid when naming HTML IDs and classes?

Some common mistakes to avoid when naming HTML IDs and classes include using non-descriptive names, using the same name for an ID and a class, starting names with a number, and overusing IDs. These mistakes can make your code harder to read and maintain, and they can cause issues with CSS and JavaScript.

How can I refactor my HTML IDs and classes for better readability and maintainability?

Refactoring your HTML IDs and classes involves reviewing your code and making changes to improve its readability and maintainability. This might involve renaming non-descriptive names, replacing underscores with hyphens, removing unnecessary IDs, and implementing a naming methodology like BEM or SMACSS.

How can I test the effectiveness of my HTML ID and class naming?

Testing the effectiveness of your HTML ID and class naming involves reviewing your code and checking for issues like conflicts, non-descriptive names, and overuse of IDs. You can also ask other developers to review your code, as they might spot issues that you’ve missed. Additionally, use tools like CSS Lint to check your CSS for potential issues.

Meitar MoscovitzMeitar Moscovitz
View Author
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week