John Allsopp, author, developer and conference organiser, has defended the “humble id attribute”.
In a Web Directions blog, Allsopp noted that prominent figures within the web industry had been dismissing the id attribute for a number of reasons, but argued these critiques didn’t really hold water. In terms of the most common criticism — the id element restricting reuse of style — Allsopp argued that’s actually “exactly what we want”.
.net spoke to Allsopp (JA) to gain further insight into why designers were arguing for the end of id and why he believed that wasn’t the correct path to take.
.net: Why did you feel id needed defending?
JA: A number of influential developers have, over the last couple of years, begun to advocate quite strongly for folks to avoid the id attribute in CSS.
In particular, this has been codified in the CSS Lint tool developed by Nicole Sullivan and Nicholas Zakas: two influential, smart, highly regarded and, rightly so, knowledgeable developers.
CSS Lint by default flags the use of an id selector with the warning, "Don't use IDs in selectors". Blanket, unequivocal. Don't. Coming from such influential people, the rules embedded in a tool like this can quickly become canonical.
.net: Do you think this is leading to a drop-off in usage?
JA: I'm not sure it is. The use of id is such an entrenched pattern, covered very early in almost any introduction to CSS, that I’d say its use will continue despite strong opposition.
However, the admonition against id selectors seems to be beginning to impact id attributes in HTML. What actually prompted my post on id attributes was a comment by Paul Irish on a post I wrote about not quoting attribute values in HTML5. He said: "Ids are totally out of fashion now due to their high specificity, so who cares?”
I'm pretty sure Irish was being ironic, but it demonstrated if we don't think carefully about this, it’s easy to conflate not using id selectors with not using id attributes.
.net: Why is this so important?
JA: Well, ids are essential for some purposes. For example, when used with forms to associate labels with input and other elements, as well as to link into parts of a document or into an application state. This all illustrates why I react strongly to any blanket warning against id selectors. The unthinking application of rules, even where those rules have value and make sense in some or many circumstances, is a really bad thing.
.net: For any designers reluctant to use id, what big benefits should they consider?
JA: Beyond the situations I’ve outlined, where they are unavoidable, I look at this in a slightly different way. My approach to development is to work from the content/functionality out. Identify within a document or application the components: this is a paragraph, this is a button, and so on. I then mark those up and style them based on the mark-up.
Sometimes as we analyse our content we'll say ‘this is a’, such as ‘this is a button’. Our first strategy is then to find HTML elements to mark-up this content. But sometimes we observe ‘this is the’ for a page. This is where id comes in, for uniquely identifying an element on a page. Whether we end up styling these elements using id selectors is a separate issue. To me, worrying about how to style a document while marking it up is a strong example of collapsing concerns which should be separated.
Developers and designers should use id attributes where appropriate or necessary. When it comes to using them with CSS, if they provide the best way to style a particular element — because we are styling this element in a particular way because it is in some ways unique — then don't be afraid to use id as a way for selecting page content.
.net: What’s your response to people arguing overt specificity is a problem?
JA: Sometimes things are unique on a page, and we want to style them in a particular way precisely because of that. For example, headers can be used repeatedly, and the rule header h1 would apply to any h1 in any header. It’s a very leaky selector. We can make it less leaky if we apply a class to the header, but the purpose of new HTML5 elements is to remove the need for classes. If we have a feature of HTML designed precisely for this semantic situation — the h1 in the page's unique header — why wouldn’t we use it? We don't care that we are restricting reuse, precisely the opposite, because we don’t want reuse.
.net: On the flip side of the argument, are there examples of id being used badly?
JA: To tell the truth, class is abused a hundred times more than id, to the point we’ve named this ‘classitis’. With excellent support for structural and attribute selectors, the need for class is in many ways much diminished, yet it's still our go-to tool for styling. I'm more likely to encourage developers to think about how they can diminish their reliance on class than be overly concerned about a rash of misuse of id.
Photograph by Drew McLellan
