Monthly Archives: January 2010

A CSS Class

Subtitle: "Stop Calling It The ‘CSS Class’"

I recently found a blog entry on Coding Horror about ‘Microformats’. Now, I’ll be honest, I don’t know much about this topic (‘Microformats’) but that wasn’t as important to me as the way that several web developers really had it set in their minds that the HTML class attribute has more to do with CSS styling than with adding semantic meaning to a document. Jeff Atwood even suggests that a problem with using Microformats (whatever they are!) is that "We’re overloading the class attribute with two meanings."

Worst of all I found the following in the comments left on the blog entry: "It’s technically wrong to overload the css class with semantic meaning."(Stefano Borini, I may not know you but I have decided I will not like you, somewhat unfairly)

Addendum: Actually, Stefano wrote to me recently and responded on his blog, agreeing with my points, and he actually seems like a really cool guy. In the end it’s not so much that I decided not to dislike him unfairly as much as I decided to dislike his opinion… and disliking someone’s opinion can be pretty fair :P (Wednesday, May 12th, 2010)

On the contrary, the class attribute is – by it’s very nature – overloaded, and – above all else – it is technically wrong to use the class attribute "to bind against a representation (style) meaning, nothing more."

The Recommendation

If you read the W3C recommendations you’ll see that the class attribute "has several roles in HTML:"

The class attribute has several roles in HTML:

  • As a style sheet selector (when an author wishes to assign style information to a set of elements).
  • For general purpose processing by user agents.

As such we see that the class attribute literally has two meanings according to the recommendation, and – if we bother to read those meanings – that one of them is actually representative of as many meanings as our web application needs. We could almost go so far as to paraphrase the above as follows:

The class attribute has several roles in HTML and can be overloaded for general purpose processing by user agents, such as style sheet selectors.

I wish they had phrased it like this, so the first role (‘style sheet selector’) seemed like a subset of the second! User agents apply styling and thus ‘style sheet selection’ could be considered a form of ‘general purpose processing by user agents.’

The heart of the issue is this; HTML is meant to describe structure and information. If you need things such as style and behavior in your web application/page, then you need other tools such as CSS and JavaScript. If those tools are to interact effectively with your structured information, your information needs to include appropriate Element Identifiers for those tools to work with. As a result, those element identifiers are inherently overloaded in meaning, as their effect will be different in the contexts of CSS versus JavaScript, versus some custom Web Scraping tool.

An example taken from the perspective of styling: if I am working on the styling of a web site, I will probably have a requirement like ‘all error messages in red’ or ‘all hyperlinks to other domains will have a little exterior-link-icon’. So you need to be able to identify all those elements which are error messages, not all those which ‘are red’. Given the nature of the requiement, you should give them a class attributes identifying and ‘grouping’ them together as error messages and you’ll want to use a value more like ‘errormessage’ rather than ‘red’. Likewise, if you have to use JavaScript to create a slide-show of all those images in a page which belong to the slide-show, you’ll want all those <img> elements in the slide-show identified as belonging to a class. (something like ‘slide-show’… again, not ‘red’)

The problem lies in that the class attribute – though it is meant to be overloaded – has come to be perceived as either inane or CSS-specific.

What to Do?

Always use class attributes which have a semantic meaning having nothing to do with presentation or style, and try and always use class attributes – even when an element does not need styling.

In particular, since <span> and <div> have no semantic meaning, you should never use them without a class or id attribute. If you do, it begs the question as to why you did, and if the answer you’re giving has to do with a tool or technology which is not HTML I may react a little childishly.

1 – Always Use Class Attributes With Semantic Meaning Which Have Nothing to Do With Presentation or Style

Let’s look at the example from the recommendation

<!-- English messages -->
<P><SPAN id="msg1" class="info" lang="en">Variable declared twice</SPAN>
<P><SPAN id="msg2" class="warning" lang="en">Undeclared variable</SPAN>
<P><SPAN id="msg3" class="error" lang="en">Bad syntax for variable name</SPAN>

You read it and it makes sense. You can imagine some styling being applied to this pretty easily. Personally, when I think of a ‘warning’ I think yellow (and it looks like Google Images agrees!) while errors make me think of red and the class ‘info’ – though a little vague and generic – makes me think of that ‘i’ in a blue circle.

So why didn’t we just do the following?

<!-- English messages -->
<P><SPAN id="msg1" class="blue" lang="en">Variable declared twice</SPAN>
<P><SPAN id="msg2" class="yellow" lang="en">Undeclared variable</SPAN>
<P><SPAN id="msg3" class="red" lang="en">Bad syntax for variable name</SPAN>

… Because that’s not scalable! Good code – and good HTML too, for those of us who don’t call it code – will still make sense when other components in the system change. It takes all of 6 seconds for a client to decide they actually want that error message in ‘Cerise’ instead of ‘red’ and when that happens, you should only have to change the CSS property in the CSS file. If you change the CSS property in the CSS file and leave a class of ‘red’ in the HTML when the element renders Cerise you’re not maintaining your HTML properly and its just becoming confusing; at that point your class attribute is bloating the HTML and you might as well have just used the ‘style’ element.

I offer a much more heavily presentation-and-styling driven example: suppose you want to implement this Image Replacement trick to heavily stylize some text. You could write the HTML the way that tutorial does…

<div>
  <span>Hello world!</span>
</div>

… or you could write it with a semantically relevant class attribute:

<div class="styling-container">
  <span>Hello world!</span>
</div>

Now any other developers working with this HTML can know – with nothing but a glance – that this <div> element is meant to achieve some sort of styling. The important part is that this doesn’t describe the styling; it merely describes the element as being a tool for styling to manipulate. Remember that the knowledge of the styling belongs in the CSS never in the HTML.

So remember that the class attribute is used most often for styling, yes, but it is not meant for styling; it’s an element identifier, and you should use it to identify elements.

2 – Try and Always Use Class Attributes – Even When An Element Does Not Need Styling

There’s no harm in including a relevant ‘class’ attribute and you should always include one, because the heart of what I’m getting at is that the ‘class’ attribute is most often used for styling but it is not meant for just styling. Even when an element does not need to be styled, include a class attribute to add semantic meaning. The real test is reading your HTML: the class attribute should increase the readability of your HTML. If you can’t read your HTML – aside from awkward indentation or spacing and entities – it’s because your HTML needs some more element identifiers. I’m not saying you should be able to read it comfortably, just that you should be able to read it at all and you should never see tags whose existence aren’t evident when you read it.

An interesting point in favor of this opinion comes from the book Refactoring HTML by Eliotte Rusty Harold. It explains why developing acessible web sites which are screen-reader friendly (by using semantically relevant markup as opposed to presentational markup) is a good plan:

(…) to assisst visually impaired users. Although currently this is a relatively small number of people with visual handicaps, in the near future this class is likey to grow quickly as audio browsers become embedded in cell phones, cars, mp3 players, and other devices aimed at people who may need to keep their visual attention elsewhere.

If after that you still don’t think you need to be able to read your HTML, consider the requirements tracability side of things. A requirement will say something like "error messages should be red" and assigning an HTML element a class of "error" introduces tracability back to that requirement. Imagine developing an entire system and then being hit with a silly design change where all error messages should be styled a particular way. This can easily be avoided by making sure you identify error messages with a class attribute, even if you haven’t been given a requirement to style them.

What to Do – continued

I’ve got two more points… less important.

3 – Never Target The Class-less Id-less <div> or <span> With CSS

Why would you do this? No, really, why would you do this, unless you were a lazy web developer or writing the CSS for inadequately id-and-class-ed HTML? One poorly thought out CSS rule…

span { padding:2px; }

Can result in really awkward spacing in some nice, semantically-relevant HTML:

<span class="fullname authorname">
 <span class="firstname">Richard</span>
 <span class="middlename">Jean-Paul</span>
 <span class="lastname">Le Guen</span>
</span>

You might think this is a ridiculous example, but you have no idea what kind of web application this HTML comes from; it may very well be necessary, and not necessarily for styling purposes.

Additionally, if you’re incorporating any off-the-shelf components, this CSS rule may interfere with them. I’ve had experiences where a CSS-reset caused the WYSIWYG editor – which the client specifically hand picked – to go completely bonkers; aparently the editor’s developers had acually developed to compensate for browser incompatabilities, and eliminating them broke the tool’s interface.

From a tracability standpoing, since <div> and <span> have no semantic meaning, you shouldn’t have reasons to target them; no client is going to say "all spans should have a border" so instead of targetting <div> or <span> target by class and id instead.

4 – Stop Calling It The "CSS Class"

It’s the ‘class attribute’. It can be used in conjunction with CSS, but it is a component belonging to HTML; an attribute to be specific. I’d like to know where this "CSS Class" term came from. It is just ‘the class’, and as far as I’ve found the standards which define it make no use of the term "CSS Class"