Kiss My Classname: A Counterpoint

I am a Zeldman fan. I admire him. I think he is a person who is smart, accomplished, and also nice. Check out his podcast. It’s great!

I was disappointed to read Kiss My Classname, his take on Atomic CSS (aka Functional CSS, aka Utility CSS, aka non-semantic classnames). I was not surprised that he is not a fan. After all, he is the original semantics crusader. What disappointed me was that the criticisms in his self-admitted rant-y article were based on what I consider to be bad assumptions.

His post was met with a lot of agreement. As a proponent of Atomic CSS, I feel compelled to provide a counterpoint, with links to real world examples to back up what I say.

First, I question the traditional idea of semantic class names to begin with. When Zeldman says “semantic”, he means relative to the content. In Atomic CSS, our class names are also “semantic” but relative to visual appearance, not content. We have tags and attributes (ARIA, etc) to describe content. Our philosophy is that visual styling should be decoupled from content.

Why is this a good thing? Real world example:
Challenging CSS Best Practices by Thierry Koblentz (Yahoo!)

“I believe the problem is a dozen people working on something without talking to each other.”

In my experience, moving to Atomic CSS (sometimes referred to as Functional CSS) leads to better communication.

I talk to my team of mostly backend developers every day. We ship new code with new features every 2 weeks. One year ago our CSS was about 80k. Today it is about 80k. Atomic CSS is a beautiful thing.

It is easier to work together when we can all look at a component and understand exactly what the CSS is doing without having to drill into a stylesheet. My team is not alone in experiencing this.

Real world examples:
Introducing Solid by Emily Brick (Buzzfeed)
Simple StyleSheets by Anton Kovalyov (Medium)

“…making things easier for yourself and other developers is not your job.”

This is an odd argument. Are we not supposed to find better, more efficient ways to do our jobs?

I do get his point, that we should not make our lives easier at the cost of the quality of the work. However, we are talking about class names. The only people who ever see class names are… other developers!

Real world example:
Naming CSS Stuff Is Really Hard by Ethan Muller (Sparkbox)

“And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.”

It is puzzling to me why Zeldman thinks that one needs to follow “semantic” naming conventions in order to create documentation.

The thing I wish he could see is that this approach can facilitate design consistency. It makes it easy to enforce a consistent design language. We do not “slap” our classes willy-nilly all over our markup. Rather, we maintain a reduced set of styles (color, spacing, typography, etc), and enforce the use of them.

Most Atomic CSS practitioners maintain our design language in a components library (html templates) rather than in CSS. Pattern libraries, yes! Style guides, yes! Documentation, yes!

When we change a component, we do so in a template. Instead of modifying CSS and HTML, we do it in one place, the HTML. If you build it right, the older a Atomic CSS project gets, the less CSS you write.

Real world examples:
Marvel Styleguide
Buzzfeed Styleguide
Tachyons Components Library

Update 3/4/2017
See also Dan Mall’s excellent article Cooking With Design Systems where he demonstrates his Atomic CSS design philosophy.

“Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.”

Is this move away from dogmatic adherence to semantic markup driven by employers who don’t value the right things, or by overworked, rushed developers? No.

The evolution of what we are building on the web today is driving us to continually question old best practices and revisit or invent ways to build things on the web. The “non-semantic” classes of today are not those of yesterday.

I appreciate where Zeldman is coming from. He spent years championing the cause of well structured code and fighting against ill-planned, sloppy, rushed websites gone wild. Everything was new and no one had any idea what they were doing. It was a mess, and in many ways still is.

However, those who are advocating new thinking about CSS are not being lazy, non-communicative, short-sighted or hurried. They are making well reasoned arguments, measuring performance, examining potential pitfalls, all the while fighting against conventional wisdom and even a little scorn.

Building and Shipping Functional CSS by Cole Peters (TrialReach)
CSS and Scalability by Adam Morse (Freelance Designer Extraordinaire)
Future CSS by J. Ky Marsh (Google)
Virtual CSS with Styletron by Ryan Tsao (Uber)

For me, Atomic CSS is about creating and following consistent design patterns that lead to performant web applications at scale. It works for me. Maybe it won’t work for you. That’s ok.

Just don’t tell me to kiss your classname.