ID vs class

Notes on choosing when to use id/class and what to use, based on URL design principles.

At time of publishing, a Google search for ‘id vs class’ returns 114,000,000 results, and ‘class vs id’ returns almost twice that. Despite a large amount of informed, well-written content (especially Chris Coyier’s article The Difference Between ID and Class) there is still confusion and debate over the exact meanings and usages of these two attributes.

The WHATWG HTML Living Standard doesn’t really let on very much about what the two elements actually mean:

The id attribute specifies its element's unique identifier (ID)

The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

An element's unique identifier can be used for a variety of purposes, most notably as a way to link to specific parts of a document using fragment identifiers, as a way to target an element when scripting, and as a way to style a specific element from CSS.

The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

So whilst there’s not much there to go on, the id attribute is commonly used in HTML as a hook for the fragment identifier — so here we can consult RFC 3986 (URI Generic Syntax), which gives us this:

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.

So, by assigning the id attribute to an element, you designate that element as a secondary resource, which may be some part of the primary resource (the resource selected by the URL without the fragment identifier).

I propose that the scope of styling a document is in itself too limited a view to decide whether or not to mark up an element with an id attribute. Taken pragmatically, the way I would encourage deciding is to think firstly “does this element represent a sub-resource”, and if that doesn’t provide a concrete answer, pragmatically ask “does a URL with this as the fragment id make sense?”.

Take, for example, the famous <div id="header"> (where that header is the page header, not the header of the principal content of the page). As the header is a site-wide, page-wide header, it is not really a secondary resource. Plus, does not make very much sense as a URL. Also, in this case, you may want to reuse header styles elsewhere, so it’d be better to mark it up as <div class="header"> or perhaps <header class="page-header">

Another example: embedding h-card data in a page.

A h-card is certainly a secondary resource, as it represents it’s own mini-document, so it probably deserves an ID. Exactly what the ID should be is a matter of course, but as the secondary resource is by reference to the primary resource, I would recommend choosing depending on what the URL represents.

Some examples: