There was a time when I was fully in agreement with Eric Meyer on the naming of classes. It made sense to me to create CSS class names based on the structure of the document. In fact, it was the only way that made sense to me.

So what changed? Me, I guess. I can’t say if I’m coming late to maturity or experience, or if I’m just getting lazy in my old age. But Edward Tufte, among others, has caused me to doubt this once-firmly ensconced principal.

What’s Tufte got to do with it? He’s nothing if not relentless in his drive to demonstrate that meaning comes from *both* semantics and presentation. Moving out of the field of computers, my grandmother would chime in on the subject as well: “Your walk talks and your talk talks, but your walk talks louder than your talk talks.” In the current context, that means that how you style your presentation will actually communicate more than what you have to say in the first place.

Oh, I remain firmly on the side of accurate semantic (X)HTML markup of the document, no doubts, questions, or hesitations there. But that this has to be carried over into CSS, into the land of presentation as well, is an idea I’m no longer willing to fight for. In fact, I’m losing my taste for it.

I’m already marking the document up consistently with its actual structure. Why is there a need to carry that over into the realm of presentation? Why is it OK to say “width: 210px” but not “.two_column” in the same document?

There’s talk of ease of maintenance. I can change all the presentation without changing the identifiers. Possibly valid, but I can do global changes with the help of editors, regular expressions and good SQL in all but the largest of sites in very little time at all. And, more realistically, I can’t remember a time I’ve wanted to rework the look of a site without reworking the markup as well; either I’ve grown better able to understand proper markup since coding the site in the first place, or the markup language has evolved to support other, more appropriate, tags.

Yes, sometimes the CSS class names chosen harken back to the age of print, and seem to lock you into the past. But I have another thought: Isn’t it really the ones talking about semantic class names that are living in the past, holding on to the idea of the eternal unchanging document, instead of recognizing that web documents are living, fluid things?

No, I’m not recommending we do as one designer I worked with at an agency did, which was to name classes as “padding10” or “margin5.” What I am venturing to suggest, however, is there is nothing wrong with naming CSS classes things like “outset_image” or “two_column_head” and suchlike. In fact, I make so bold as to suggest that those kind of names are even easier to maintain, because they follow along with the proven successful developer strategy of making the purpose of variables, methods and classes as obvious in the name as possible.

The (X)HTML markup will tell you the text in question is a heading, let the CSS classes let you know that it’s a “two_column screamer.” The writer crafts the document structure and the words, but the designer handles the presentation. It’s only logical, then, that the text markup should follow the terms and labels familiar to the writer. Just as it’s only logical that the CSS follows the terms and labels familiar to the designer, the one in charge of the presentation.