Opinions of Leaders Considered Harmful

Published on (01-22-2017).

Note: this started as a rebuttal to Jeffrey Zeldman’s piece (Kiss My Classname) but I thought there was more to it, hence the title…

I disagree with many things Jeffrey says:

Nonsemantic classnames that refer to visual styles will always be a bad idea. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.


I was there and I do recall the issue with HTML, but I fail to remember what “non-semantic CSS did to the Web”. So I searched the Internet…

“Non-semantic CSS”? Not so fast…

Here is a “useful bit of knowledge” for Web developers or designers, hosted and produced by the Quality Assurance Interest Group at W3C:

Use class with semantics in mind.
Often people use class names like bluetext, or redborder. A much better way to name your classes is with the role a certain HTML element of that class has.


Articles often link to this as if it was some sort of golden rule from the mothership but it is not. If you read the “fine print” it says:

While the tips are carefully reviewed by the participants of the group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.


Yes, this is not a W3C recommendation. Not only that, but this “bit of wisdom” is from 2004! A time when markup like this:

<div class='SidebarBox'>

was considered better than this:

<div class='SidebarBox'>
 <ul class='SidebarList'>
  <li class='SidebarListItem'>signals</li>
  <li class='SidebarListItem'>noise</li>

Back then, “best practice” was to use as few classes as possible but the popularity of BEM confirms that this is no longer good advice.

Here is more from the W3C

That “Tip for Webmasters” page links to a “draft” from 2003 titled “Separation of semantic and presentational markup, to the extent possible, is architecturally sound”.

Section 3 (Abstraction and Concreteness) says this about “semantics”:

There is no hard and fast division between what is ‘purely semantic content’ and what is ‘just presentation’. The term "semantics" is often used or misused in this context, however any structured format is likely to have some semantics; and some semantics refer to precise details of presentation. Thus, ‘semantics’ is not used in this section.


So even though that doc is about “separation of concerns”, the author acknowledges that the concept of semantics does not pertain to the issue.

In fact, the “problem statement” makes it clear that it’s not about “semantics” but is instead all about restyling:

The actual problem seems to be that some content has made inappropriate design choices that limit restylability [sic].


The next section doubles down on that:

These examples show that an identified problem is lack of access to restyled content, [...]


Restyling it is

While researching about the SoC (Separation of Concerns) principle as it relates to HTML and CSS, I found this slide deck from last year by Elika J. Etemad titled “CSS Best Practices”.

For those who do not know, Elika (aka fantasai) writes CSS specs.

The slide that relates to the discussion at hand is this one:

Foundations: Separate Content and Style
  • Use Semantic Markup
  • Classes for meaning, not for show.

It may require a bit more analysis, but it is always better to think of class names that represent the meaning/function of the specific element(s) rather than what happens to be their current presentation. That way when their presentation changes (as it inevitably does), or alternative presentations are designed for additional media types or devices, you avoid such confusing style rules like:

.black {color:navy;}


The statement in that slide does not suggest changing the markup, replacing .black with .navy, but rather editing the declaration in such a way that it makes no sense for anyone—including those who are in favor of Atomic CSS (since Atomic classes/styles are immutable).

The real issue with people who see presentational classes as evil is the fact that they cannot fathom authoring styles outside of a styles sheet—they just cannot. And it is that bias that perpetuates the idea that “Atomic CSS” is one of the worst practices ever.

CSS-Tricks seems to take a similar stand:

<div class="left"></div>

Unsemantic. Perhaps in the Theoretical Redesign Future™ you’ll want this stuff on the right instead. Too specific.


suggesting that .left will prevent a redesign—a restyling. But authoring at the template layer does not mean to change the meaning of a class like .left; it simply means adding or removing that class from class attributes.

So here we have it, we’re obeying a 12-year-old rule because we’re told it facilitates restyling via Styles Sheets. But what if people don’t care for that? What if it is not their concern? Why should authors obey this practice if it is not pertinent to their job?

This is going too far

In “What Makes For a Semantic Class Name” we can read:

<div class="clearfix"></div>

Unsemantic. [...] it has nothing to do with the content it contains, thus unavoidably unsemantic. Dan Cederholm recommends a more feel-goody class name “group” for this purpose instead (in his book Handcrafted CSS), which, to me, just barely brings this into the realm of semantic, as certainly this wrapper contains multiple other elements and is thus a group (describing without specifying).


To me, this makes absolutely no sense. .group is a class that is too generic for the content layer and too abstract for the presentational layer. In other words, it may “feel-good” (as Chris hints) but it does not facilitate one’s job.

I had already witnessed the same kind of “logic” while at Yahoo!, finding rules in repos that resembled to the one below:

ol:after, ul:after, .md:after, .md-sub:after, .hd:after, .bd:after, .ft:after, .fixfloat:after, .fbody:after, #colcx:after, #rightcx:after, #eyebrow:after, #masthead:after, #search:after, #tabs:after,  #doors:after, #patabs:after, #patop:after, #trough-overlay-bd div:after, #newsft:after, #newsbottom:after {

That code snippet is 10 years old, but don’t think this method of applying “clearfix” is passé; because I see plenty of code examples where pre-processors promote such approach:

.elementWithTremendousSemantic {
  @include clearfix;
  background-color: teal;

Please think about this for a minute…
Here, authors prefer to add selectors to a styles sheet rather than using a unique class (i.e. .clearfix) across documents.

WTF? If there was one single case where a presentational class should be considered the best tool for the job, then it should be that one, because using .clearfix leads to less bytes in styles sheets and requires no maintenance. Without mentioning the fact that constantly editing styles sheets (to add or remove selectors) leads to cache busting. That’s 3 strikes against that approach. It just makes no sense. Don’t do it!

Been there, done that

Note that the fact that I’m criticizing the “do not use class for show” rule does not mean I don’t understand the benefits of “semantic hooks”. I know about CSS Zen Garden (I even contributed to the project many many years ago) and most importantly I leveraged that very idea while working for Yahoo! Small Business—building many different templates based on the exact same markup.

So yes, I know the value of non-presentational classes when it comes to restyling

Reality check

I think “semantic CSS” is pretty much disconnected from today’s authoring workflows and goals. For one, I know many devs for whom the famous advice (“use classes for meaning, not for show”) and example (.black { color: navy; }), are irrelevant to the discussion, because for them:

If one’s effort is geared toward writing as little CSS as possible, then the solution is to stay away from the general idea of “semantic selectors” because that’s where the danger lies…

In “Between the braces”, Jeremy Keith writes:

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?


Scary stuff! At least, with “Atomic CSS” authors don’t sweat these two:

Using “semantic CSS” means relying on the same markup while worrying about name collision. Using “Atomic CSS” means reusing the same CSS without worrying about name collision. Those are fundamental differences. That, as well as the fact that “semantic CSS” styles sheets balloon while “Atomic CSS” styles sheets plateau.

Back to what Jeffrey says

I’ve worked on big sites and I understand how bloated and non-reusable code can get


Yes, and I bet that “bloated and non-reusable code” is code based on the SoC principle. In my experience, “Semantic CSS” promotes style isolation and redundancy which leads to “bloated and non-reusable code”. Namespacing does not help either…

On the other hand, Atomic CSS promotes code re-use which reduces bloat. And because classes are not related to content, name collision is not a concern.

If the goal is to reduce the amount of CSS your team is writing then it is more efficient to invest in a solution designed to reduce bloat than one that was never meant to address bloat.

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


Communication is not always easy or even possible. Large projects may involve a lot of people (dozens with a “s”); from different teams, different locations, different time zones… “Turn-over” is also something that needs to be factored in because keeping people in the loop is one thing, but onboarding people is another. The documentation for new hires can be daunting as there is a lot to assimilate:

The more you have to communicate, the more chance you have that some information will be lost.

I also think it is better to implement solutions that involve less decision making as it reduces the number of people who need to get involved in discussing change requests. The goal should not be to better communicate, but to require less communication.

Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you


Yes, it does, and that’s extremely important when working for a large organization because it reduces the cost of transfer of knowledge (among other things). Note that the benefits of “styling via markup” go way beyond simplifying the reading of styles attached to an element:

Think of the styles sheet as global scope and markup as local scope. It is safer/easier to edit styles attached to a HTML node than to edit rules in Styles Sheets.

especially if you don’t document your work


We all know that the best code is code that does not need to be documented. “Atomic CSS” classes speak for themselves—”Atomic CSS” rulesets are assertions that don’t need comments.

But making things easier for yourself and other developers is not your job.


This is an interesting remark because in my experience, ACSS (a “Dynamic Atomic CSS Library”) is not perceived as a dev-centric solution (to the contrary). At Yahoo!, most complaints came from FEE (Front-End Engineers) who found it was a burden to implement (compared to the classic “semantic CSS” approach). Nonetheless, our job was to develop an architecture that would first and foremost make our CSS smaller, to increase performance, to give our users a better experience.

Worrying about CSS maintainability is dev-centric; focusing on minimizing bloat/leveraging caching is user-centric That's all there is to it

— Thierry (@thierrykoblentz) January 21, 2015

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries.


I really don’t think communication is the magic wand that can keep CSS from becoming a big ball of mud.

When it comes to large projects and decentralized teams, communication may help fix problems, but it may be more rewarding to fix the root cause of these problems. Spaghetti code is the by-product of architectures that rely too heavily on knowledge sharing.

Style guides do bring coherence but they do very little in regard to bloat (as a side note, a static Atomic CSS styles sheet helps enforce style guides).

And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.


We need to be able to work fast. What we need to achieve is keeping that fast pace while producing code that is lean, easy to understand, and easy to maintain.

In a fast moving environment throwing away code is a given, so it is important that your architecture preserves you from producing dead code—creating technical debt. With Atomic CSS, there is no need to clean up rules in styles sheets each time you throw away a component. That’s because markup and styles are tied together.

If you think methodologies that keep template, logic, and styles together (i.e. inside component directories) offer the same benefits, then think again… Because approaches that “stitch” CSS files together create highly volatile styles sheets which further reduces the chance that those files will be fetched from cache.

I have been there too. When the SoC principle was still sacred at Yahoo! we bundled styles sheets like so:


which is a very inefficient approach when it comes to caching.

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along,


Employers who value quality in CSS and markup are a rarity but what is worse is that the majority of front-end “employees” are not even proficient in HTML and CSS. That is a reality we need to deal with. This is why it is more realistic to invest in processes that are easy to implement rather than trying to educate people who may not even be interested. After all, there is a reason why Bootstrap is so popular.

resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.


If I wrote Challenging CSS Best Practices it is because I realized that the work process we worshipped all these years was not suited for complex environments. Coming up with a solution that departed from “semantic CSS” is what solved most of our problems.

The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach.

I think folks should stop using the “semantic CSS” argument against solutions like Atomic CSS for the simple reason that this reasoning is fallacious (see appeal to belief). For one, if “semantic CSS” (as defined by its supporters) was a real thing, I’d expect Assistive Devices to make sense of classes.

If your way of writing HTML has changed over the years then it makes sense to change the way you write CSS, to take advantage of that change https://t.co/3TMEL7tCCL

— Thierry (@thierrykoblentz) October 31, 2016

Going back to the original “Tip for Webmasters”, we read:

Bad names
An advantage of using CSS is that you won't have to change much in order to change the looks of your website. If you have to change all light text into dark text, and thus change all classes lighttext to darktext in all your HTML pages, you're likely to miss a few.


The key here is this piece:

“and thus change all classes lighttext to darktext in all your HTML pages”

That’s the real issue. It has nothing to do with semantics; it relates to maintenance. If your workflow requires you to make changes in different places whenever you want to change some styling then you should leverage what styles sheets can do for you, but if your environment makes it easy to add, delete, or edit classes through markup, then take advantage of “Atomic CSS” because it means writing less CSS—much less.

All it takes is clarity and communication.


Or, perhaps, an open mind…

More of the same opinion from our leaders

Now is a good time to go get some popcorn… :)

Huh, just came across https://t.co/TgjqOJhZDW for the first time.

Worst web dev idea of all time, or just a really bad one?

— Dave Shea (@mezzoblue) November 4, 2016

Read a post on CSS & threw up in my throat a little. *Never* do this:

<div class="flex p1 red">

Don’t repeat the mistakes of the past.

— Aaron Gustafson (@AaronGustafson) June 15, 2016

“…well what about the class?”
“uh… maybe like, put some math in there?”
“k.” pic.twitter.com/ZSto8qAmje

— Scott Jehl (@scottjehl) September 27, 2016

I really don’t understand why anyone would ever want to write CSS through/like this. http://t.co/mIvC8ys7W8

— Sara Soueidan 🐥 (@SaraSoueidan) May 24, 2015

With tweets like those, sycophants miss an opportunity to learn something:

@LeaVerou @AtomicCSS Say bye bye to AtomicCSS. THE expert deemed it unworthy...

— Wouter Dingemanse (@W_Dingemanse) January 11, 2016

I think it's better to inspire people...

You can write “CSS” in:

.css (not kidding)
.js (React etc.)
.html (Atomic, Tachyons etc.)

Choice is nice.

— 🤖 (@simurai) March 13, 2016

In French we have a saying:

Si tu n’aimes pas ça, n’en dégoûte pas les autres!

(If you do not like it, do not turn others off from it also!).

Further readings