In issue 406 of A List Apart, Heydon Pickering writes about "Axiomatic CSS and Lobotomized Owls". I have to admit, the title had me chuckling a little. The subject is mostly clever use of selectors to ensure things like consistent margins and padding inside of a component. I’m fine with that: I think we should make as much use of clever selectors as we can. I’ll probably experiment on the lobotomized owl. It’s also a criticism of methodologies with a liberal use of class names as presentation hooks—which is fair enough. I’ll try to offer some counter-points to that.

I do take issue with one aspect of the article, and that’s the connection between naming schemes and accessibility. Heydon identifies elements and attributes as predetermined and standardized, and classes as where we as authors are allowed freedom of choice. He goes on to describe how he sees the use of classes as styling hooks:

CSS frameworks are essentially libraries of non-standard class-based ciphers, intended for forming explicit relationships between styles and their elements. They are vaunted for their ability to help designers produce attractive interfaces quickly, and criticized for the inevitable accessibility shortcomings that result from leading with style (form) rather than content (function).

(Emphasis mine)

(It’s a bit weird to point out that classes are "non-standard" right after explaining that they are not meant to be, and a bit rich to classify them as "ciphers", which, to me, implies that they are hard to understand. That depends on the class name, no? But I digress.)

Heydon goes on to give an example of how these accessibility shortcomings look:

<!-- An unfocusable, semantically inaccurate "button" -->
<a class="ui-button">press me</a>

The turn

To me, this is a serious case of misdirection. Dissecting the example, it’s a link that is supposed to be styled as a button. So far, it’s not terrible: it’s a UI component that you click and something happens. But the important part is what’s missing: it doesn’t have an href attribute, so it can’t be focused.

We are dealing with incorrect HTML here. The presence of the class name .ui-button does exactly nothing to change the accessibility of the element. None whatsoever. That is hardly an "inevitable shortcoming" of neither liberal use of class names nor CSS frameworks.

Conversely, we can either add the href-attribute (with a useful value), or change the element into a <button> element to fix the accessibility issue. (Depending on the rest of the page structure, either could be correct.) The class name identifying this component as part of the ui-button class could still be there, still doing nothing to change the accessibility of the document. I’d argue that it doesn’t change the semantics of the HTML document either.

If you’re shouting "but what about microformats!" or "class names can too be semantic!" from your chair: calm down, all is not lost. I don’t dispute that in a wider sense, class names may be part of the semantics of the code. We can parse the page for microformats or other indicators that let us do useful things based on them. This is the part where I remind you that you can have your cake and eat it too: the class attribute can take multiple space-separated values. Jeremy Keith wrote about this (and about not being dogmatic about these sort of things) in his post "Classy values".

Why does this misdirection bother me so much? Well, it’s not the first time I’ve seen it. When discussing how to structure and name things in CSS (and HTML), there is a strong trend towards allowing class names that describe the "visual semantics" of an element (borrowing an expression from Nicole Sullivan). This is decried by some as "unsemantic", and in some cases (like Heydon’s article) bad for accessibility.

Yet, I have not heard a single good argument for why that is.

Why not to use presentational class names

The HTML5 spec has the following to say about class attribute values:

...authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

Encouraging class names that describe the content rather than the presentation of that content makes a lot of sense: it prevents mixing of concerns. Separation of Concerns (SoC) is a fundamental principle of software construction: working on one part of the code shouldn’t mess with another part, and the boundaries should be clear. That is the one big reason for not having presentational class names in your HTML: code quality. Not semantics, not accessibility.

Why you would still use (somewhat) presentational class names

CSS is a declarative language meant to be easy to pick up. You don’t need to have tons of programming experience and understand functions and objects and modules to use it. Instead, CSS has a wealth of properties that you can manipulate, one by one. What it doesn’t have is built-in mechanisms for scoping and structuring your code.

This means that CSS is "bring-your-own-structure". Some people, like Nicole Sullivan, Harry Roberts and others, have come to the conclusion that keeping class names and id:s strictly describing the nature of the content leads to messy and bloated CSS. If you are grouping things not on what presentation they create but what type of content they hold, you often end up with fragmented and repeated CSS. Their response (if I’m representing them correctly) was to break the principle of SoC, and introduce class names (and naming conventions to go along) that are more geared to what function they have from a presentational perspective. Having a strong naming convention helps with understanding which class names are part of presentation, and which describe content or other aspects of the code.

The result is a shift of complexity from CSS to HTML. You get somewhat verbose and chatty HTML, but CSS that is, hopefully, easy to read, well-structured and highly performant. Mind you, I still think that there is a line here: when I say "presentational class names", I mean things like .standout for elements that should stand out visually (maybe with a border, contrasting color or shadow), regardless of their content or context. I wouldn’t kick the .ui-button class out of bed either. I would however personally not use something like .margin-top-20.

The argument

The idea is that it’s easier to perform the somewhat binary operation of adding or removing a class name in your HTML than refactoring unstructured CSS. We are increasing complexity in one part of our code while decreasing it elsewhere, and hopefully we’ll have a net gain. Heydon obviously has a different take on this, and thinks that the increased weight on HTML actually increases bloat. I’d argue that there is a whole bunch of straw men in that section of his article.

Whether you use a framework or your own methodology, the prescriptive styling mode also prohibits non-technical content editors. It requires not just knowledge of presentational markup, but also access to that markup to encode the prescribed styles.

and...

By choosing to style entirely in terms of named elements, we make the mistake of asserting that HTML elements exist in a vacuum, not subject to inheritance or commonality.

I’d say that no-one styles entirely in terms of named elements. Having a sensible default style for elements that should obviously be visible on the page (buttons, links, headings, paragraphs etc) is not negated by having named specific modules. I’d be hesitant to have a default appearence for div:s though.

As for non-technical content editors, they rarely edit the whole page, but rather parts of it. I usually have a class name (like .flow or .prose) to scope a specific part of the page (like an article coming from a CMS) where each element has very basic styles, designed specifically to be as allowing as possible, without interfering with any of the other UI of the page.

Jeremy wrote another article about this stuff recently, where he described how the non-technical staff of Code for America that actually do build whole pages required them dial down some of the named elements in favor of more complex CSS. So yes, it’s not black and white.

Adding new modules to a project invites bloat, which is a hard thing to keep in check.

Yes, if we buy the premise that a specific methodology inevitably invites bloat, which makes this a very circular argument.

Some interpretations of object-oriented CSS even insist on a flattened hierarchy of styles, citing specificity as a problem to be overcome—effectively reducing CSS to SS and denying one of its key features.

I’d argue that no methodology I’ve encountered sees specificity as a problem, but recommend against using id:s and long selector chains as they become too specific.

The conclusion

So. This stuff is arguable.

Personally, I think that the "visual semantics" approach that I’ve tried to describe is better on most counts. A few years ago, I didn’t. Maybe in a few years, I will be back to thinking that it’s bad. And all of the time, I will be thinking that people who use inaccessible HTML are jerks. All of the time, I will probably be avoiding class names that describe a specific value, such as .blue. All of the time, I will be combining class names I use with ones that add other values than presentational. All of the time, I will be trying to learn as well as educate people on writing accessible code.

But writing accessible HTML is a completely different matter than deciding on class names or naming schemes. So please keep them separate.