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 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).

At this point Tim and Roy really get into their stride, and pull out some looong words:

The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the
primary resource. The fragment's format and resolution is therefore
dependent on the media type (RFC2046) of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced.

Translation: The exact meaning of a fragment identifier (and therefore an id attribute) depends on the media type (e.g. text/html, application/json, etc.) of the document you get when you dereference (request and load) the URL. The scope of the ID vs class confusion is limited to HTML, but it is important to note the background to the ID vs class argument is not limited to HTML.

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, http://example.com/blog/some-post#header 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">

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:

On a personal homepage, I would give the h-card id=me, so the URL to the h-card representation is http://example.com/#me