Standardizing CSS class and id names

Web builders create CSS class and id names to identify divs and other page elements for formatting. columnist Michael Meadhra shares his thoughts on emerging naming conventions.

This article originally appeared in the Design and Usability Tactics e-newsletter. Click here to subscribe automatically.

Web builders can create CSS class and id names and use those names to identify divs and other page elements for formatting. The CSS selectors that redefine XHTML tags must match the predefined tags exactly, but class and id selector names are totally at the discretion, ingenuity, and whim of the Web builder. However, it may not be the best practice to follow whims in class and id naming.

After reading a series of articles by Andy Clarke (of Stuff and Nonsense and All That Malarkey) and Eric Meyer that address naming conventions for CSS classes and ids, I began to think about the way I name classes and ids on my sites.

Presentational naming

When you're working on a Web page and need to come up with an identifying name for a div, the natural temptation is to use a name that describes the element's page location. This approach leads to class and id names such as the following:

  • top-panel
  • horizontal-nav
  • left-side
  • center-column
  • right-col

These are all valid names for CSS and XHTML classes and ids. They're simple and descriptive, so they serve the purpose of identifying the page element and its corresponding CSS style.

The problem is that such names relate to a specific presentation of the content. They reference the position of page elements in a particular page layout, and may be inappropriate and confusing outside the context of that layout. And, these names don't say anything about the structure of the document content. There are better ways to name your CSS classes and IDs.

Structural naming

True structural markup means completely separating presentation/position information from the content—that includes class and id names that appear in the markup.

The goal is for all markup to relate information about the document's structure rather than its presentation. This facilitates reusing the content and markup in different presentation formats by simply changing the CSS. When you think about it, it's easy to see that class and id names that refer to page position are inappropriate in presentation formats such as audio. Therefore, structural naming names classes and ids by their purpose in the document, not their location.

Taking a structural approach to naming might produce class and id names such as the following:

  • branding
  • main-nav
  • subnav
  • main-content
  • sidebar

These names are just as descriptive as the presentational names, but they describe what the page element does, instead of its location. The result is code that is much closer to the goal of pure structural markup that designers can format for various presentation media without changing the markup.

Even if you don't plan to format your Web page for presentation in other media, using structural naming can help make future updates/redesigns easier. For example, structural naming eliminates the confusion that would arise if a div with the id right-column moves to the left side of the page. Naming the div sidebar is much more appropriate, and the name remains valid no matter which side of the page it's on.

Emerging conventions

Andy Clarke looked at the code of 40 Web sites by builders with reputations for espousing standards-compliant Web design. Although class and id names were far from uniform, some common names did show up frequently. Here's a sampling of the most common class/id names:

  • header
  • content
  • nav
  • sidebar
  • footer

For the full list, see this table of most popular naming conventions.

Do these common class and id names constitute an emerging standard or the beginnings of a widely accepted convention? I don't know, but I hope so. I welcome a set of standard names for the common page elements we see every day. Also, using standardized naming conventions would make it easier to find and update common page elements—especially when you need to move from site to site, working on sites that different builders created at different times.