It seems like a lifetime ago that I first sat down with a cup of tea and a bourbon biscuit and thought about the conventions that we use for naming HTML/XHTML id and class attribute values.
Not quite a lifetime, but it was way back in May 29th 2004, on my retired blog And All That Malarkey, when I surveyed forty designers' sites to see what conventions they used for common page elements like headers and banners, navigation, content and footers
(the results at the time).
It was hardly scientific research but in June that year I followed up on some comments by Eric Meyer and published a set of naming conventions. I am always really pleased when I find a site that has adopted these naming conventions and I still use them every single day, even over four years later.
My thoughts at the time can be summarized to this.
id and class attribute names must reflect the function or content of an element, rather than reflect presentation. So out went header and in came branding; out went footer and in its place came site-info.
Naming should take on almost an XML style structure. So inside content came content-main, content-sub and content-supp.
These conventions have served me well and I've made almost no changes to their core. Without doubt, they have made my work faster, more consistent and more profitable. They made it easier to build products and easier to train people I work with in my way of thinking. Naming conventions work.
Enough bourbon biscuits to sink a battleship
In four years a lot has happened (and I've eaten enough bourbon biscuits to sink a small battleship). I've seen so-called CSS frameworks developed and grow in popularity. I've seen mighty Microformats bring their set of class attribute values based upon existing standards such as vCard. I've also watched the popularity of JavaScript frameworks such as jQuery grow and with them plugins and markup library items for all manner of interface behaviors.
While my thinking about the importance of naming conventions hasn't changed one byte, my own conventions have evolved. First in relation to Microformats and recently in relation to HTML5.
Microformats and associated attribute naming
Let's face it, Microformats such as hCard, hCalendar, hAtom and other drafts bring with them so many attribute values that it's often not necessary to think of more values by which to structure a document or provide hooks on which to bind CSS styles. I now use Microformats so much that I've even developed whole pages that contain no class attribute values other than those that come with a Microformat.
On the rare occasion where I need to add a new element (let's say a div for layout purposes), my first thought is to extend what is already there in a Microformat. I'll give you an example using the hAtom schema:
<div class="hentry">
<h2 class="entry-title">Title</h2>
<div class="entry-content">
Main content
</div>
<div class="entry-related">
Related content
</div>
</div>If you're keeping on top of Microformats, you have noticed that entry-related is not part of the hAtom schema, but in a situation like this where I absolutely, definitely have to have an additional element, why make up an attribute value like related-sidelinks when extending the Microformat's naming schema seems so much more logical?
HTML5
I should preface this section by saying that frankly, I couldn't care less about HTML5 at this point in time. Still, that's not really the point. HTML5 introduces some potentially very useful new elements such as:
section- A generic document or application section. A section, in this context, is a thematic grouping of content.
article- A section of a page that consists of a composition that forms an independent part of a document, page, or site. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.
aside- A section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
As it was logical for the inventors of Microformats to base their schemas on existing specifications, surely it now makes sense for me to adapt my naming conventions to follow those in HTML5? Of course I can't yet use:
<section>
<h2> Title</h2>
<article>
Main content
</article>
<aside>
Related content
</aside>
</section>But I can use id and class attribute values to help me get familiar with HTML5 and bring my documents a little closer to it now.
<div class="section">
<h2> Title</h2>
<div class="article">
Main content
</div>
<div class="aside">
Related content
</div>
</div>This seems to me to be a logical next step for me to take. So take a look at this demonstration file in which I've taken HTML5 elements as the basis as my naming conventions. In addition to the ones I've just mentioned, look out for the way that I've classified and identified navigation (nav), built columns with colgroup and col and turned an unordered list into a grid with datagrid.
The HTML5 markup specification also includes details, dialog and figure that I could use now as attribute values in the same way.
If I could have one wish fulfilled today, it would be that all CSS framework developers would adopt the same naming conventions (and embed Microformats extensively too), so that people who are new to meaningful markup and CSS get off to the right start and use meaningful, logical rather than presentational id and class attributes.
I'm glad that my naming conventions have worked so well for me and I think they deserve a little tender, loving updating once in a while to keep them relevant.
Oh, and it also means that I can justify eating more biscuits.