Reuse or not reuse…

Published on (05-26-2016).

I didn’t have much to do today so I thought I’d take that bait:

Atomic CSS vs MaintainableCSS, FIGHT !
(cc @thierrykoblentz @iamtzi @HTeuMeuLeu @htmlvv )

— Raphaël Goetter (@goetter) April 25, 2016

Plus, the author of MaintainableCSS is inviting me to do it:

@thierrykoblentz Would love to hear your view, in particular how you would solve all the problems addressed in Semantics and Reuse 🙂

— Adam Silver (@adambsilver) May 25, 2016

So here goes…

It Says Don’t Try To Reuse Styles

This is the’s TL;DR:

Don’t try and reuse styles. Adopt a duplication-first approach.

In other words… write more css!

It Says Reuse Can’t Do Breakpoints

The author claims that one can’t use Atomic CSS to build a 2 column grid that:

This is his markup:

<div class="grid">
  <div class="col pd50 pd20 fs3 fs2">Column 1</div>
  <div class="col pd50 pd20 fs3 fs2">Column 2</div>

As a side note, I’m not quite sure what the following implies:

Note: “column” is now misleading.

Does that refer to the col class he chose to include in his example? Because in proper “Atomic CSS parlance”, there is no such thing as a col class since Atomic CSS classes are mostly related to property/declaration pairs. Same thing with the grid class used on the wrapper- that’s not Atomic CSS either; those are usually called “utility classes” or “helper classes”.

A more realistic example would be:

<div class="overflow-hidden">
  <div class="float-left width-50% width-100%__small-screen padding-50px padding-20px__small-screen font-size-3em font-size-2em__small-screen">Column 1</div>
  <div class="float-left width-50% width-100%__small-screen pd50 pd20 fs3 fs2">Column 2</div>

Note: I am being very verbose here to make things easier to understand for people who are not familiar with Atomic CSS.

I style the wrapper with overflow:hidden to create a block formatting context that will contain the 2 floated boxes (the author forgot to include styles for layout). The width of 50% will create the 2 columns; the following class (width-100%__small-screen) is attached to a rule which is inside a media query. It will kick-in in narrow viewports. Same thing for the other classes with __small-screen suffixes- all those are dormant until they become relevant (plain MQ stuff).

So here we have it. We have a module based on Atomic classes in which styles change according to breakpoints.

As a side note, if you do not like the fact that on small viewports the value of font-size is not 3em although a class says font-size-3em, then feel free to take a different approach and sandbox both styles inside different MQs (i.e. font-size-3em__large-screen and font-size-2em__small-screen). Personally, I don’t see much value in that but you should know that this can easily be addressed.

You can also check Bootstrap v4—they seem to use a similar approach:

<div class="pull-sm-left">Float left on viewports sized SM (small) or wider</div>
<div class="pull-md-left">Float left on viewports sized MD (medium) or wider</div>
<div class="pull-lg-left">Float left on viewports sized LG (large) or wider</div>
<div class="pull-xl-left">Float left on viewports sized XL (extra-large) or wider</div>

It Says Class Names Are Crazy

You can see this just isn’t going to work. You now need some crazy class names such as fs3large.

Is fs3large a crazy name? Why?

This is what Nicolas Gallagher says about classes:

Class names should communicate useful information to developers. It’s helpful to understand what a specific class name is going to do when you read a DOM snippet, especially in multi-developer teams where front-enders won’t be the only people working with HTML components.

Call it crazy, but I think fs3large does a pretty good job in that regard. Actually, even though I did not choose that class myself, I had no problem guessing its purpose. And this says a lot about Atomic classes; you do not need to be very familiar with a project before you can use them wisely. And those classes come with no strings attached. Meaning when you use an Atomic class, you know exactly what it styles and how it styles it.

It Says It’s Too Many Tasks/Rules

Alternatively, take the following semantic mark-up that doesn’t attempt to reuse styles:

<div class="someModule">
  <div class="someModule-someComponent"></div>
  <div class="someModule-someOtherComponent"></div>

Ensuring this is styled as specified [earlier], is now a simple task with 6 CSS declarations needed in total, 3 of which reside within media queries.

That’s for a single module—which begs the question: how does that scale?

Is it 6 declarations for 1 module? 60 declarations for 10 modules? 600 for 100 modules? And so forth?

Tightly coupling styling with modules leads to writing redundant declarations each time a new module is created. An approach that leads to the most dreaded CSS issues:

With Atomic CSS, there is no such thing as creating more CSS each time you create a new module for the simple reason that you can pull/reuse existing styles—declarations to which you have access because they are not tied to any particular element.

It Says It Can’t Work Because Styles Change Based On States

How do you make <a class="padding-left-20 red" href="#"></a> to have padding 18px, a slight border, a background of grey and a text color as a slightly darker shade of red when it’s hovered or focused of active i.e. :hover,:focus, :active etc?

The short answer is you can’t. Try to avoid having to fix self-induced problems.

Nope again! We can do this via a particular syntax. For example, using the one from, we can change the background color of a box on mouseover like so:

<div class="Bgc(#0280ae):h"></div>

The corresponding CSS rule being:

.Bgc(#0280ae):h:hover {
    background-color: #0280ae;

And in case you do not like the escape characters in there, no worries, with Atomizer you do not need to write CSS rules—that tool does it for you. Which means if the style changes for some reason, or if the element attached to it is removed, you do not need to edit the styles sheet to reflect these changes because the tool does that for you!

It Says Reuse Makes Debugging More Difficult

When debugging an element, there will be several applicable CSS selectors playing a part making it noisy.

Because granular styles aren’t worth bothering with.

This sounds more like a statement than an actual argument.

When using Atomic classes, one can change the value of any class and see it propagates through the entire document, which is possible for all properties, even the ones that do not inherit—for example, one can change the padding of all modules at once directly from the web inspector.

It Says Class=Red Is The Same As Style=Color

If you’re going to do <div class="red"> you may as well do <div style="color: red"> which is more explicit anyway. But we don’t want to do this because we don’t want to mix concerns.

No, it is not the same, not at all:

So no, it’s not the same; it is not even close. And saying we do not want to do it because “we don’t want to mix concerns” relates to some “best practice” from way way back. Things have changed, including the importance of the SoC principle since we are now using JavaScript to write HTML.

It Says Visual Class Names Don’t Hold Much Meaning

Take red. Does this mean a red background? Does this mean red text? Does this mean a red gradient? What tint of red does this mean?

This looks like a red herring 😉

Using red as an example of a Atomic class name is misleading because by definition - and as stated earlier - Atomic classes look more like declaration/value pairs:

As a side note, why does the author wonder what tint of red red means? red is a valid color keyword so there is no guessing here unless you purposely decide to ignore any semantic a class may suggest.

It Says Updating a “Utility” Class Applies To All Instances

This sounds good but it isn’t. You end up applying changes where you didn’t mean to.

My guess here is that the author means changing the value of an utility class. This again shows a lack of understanding of how Atomic classes work. A class name is made up of both a property and a value (with some degree of abstraction), so changing the value would mean to change the class itself.
In other words, there is no such thing as upgrading border-green so it looks blue. What authors would do is replace border-green with border-blue which will not have any effect on border-green.

In fact, this can be seen as a feature since it prevents modules from being altered unwillingly.

There is more:

Think regression. Alternatively, you end up scared to touch this utility class so you end up with .red2. Then you end up with redundant code. Obviously this is not fun to maintain.

.red2 is another example that has nothing to do with Atomic css. Authors never have to fear to change a style, because those are immutable by definition; all authors need to do is create a new class for that new style. And that’s not redundant code, because regardless of the approach you take, you’ll be using different classes for different values.

It Says Non-semantic Class Names Are Hard To Find

If an element has classes based on how it looks such as .red, .col-lg-4 and .large, then these classes will be scattered all over the codebase so searching for “red” will yield many results across the HTML templates, making it hard to find the element in question.

This is another moot point because “Atomic CSS” does not forbid you to use classes related to content in your markup. Check, that site even uses id for Christ sake!

As a side note, the author adds:

If you use semantic class names, a search should yield just one result. And if it yields more than one result, then this should indicate a problem that needs to be dealt with.

“Looking for a class should yield a single result”? Then why using class in the first place? If you prone semantics then walk the talk and use a id for anything meant to be unique on the page. That will not only be more semantic, it will also help devs author rules with more confidence (due to the narrow scope of that selector).

It Says Reuse Causes Bloat

If you attempt to reuse every single rule you’ll end up with classes such as: red, clearfix, pull-left, grid which leads to HTML bloat:

<div class="clearfix pull-left red etc">

This is a false assertion as it mostly depends on the syntax. In the case of ACSS (Atomic CSS powered by Atomizer), classes are relatively short. We did gather some data and found out that this is not necessarily true, which makes sense as the author’s own examples show:

Meaningful names related to content have a tendency to be rather long (i.e. Twitter has PermalinkOverlay-with-background). Most importantly, semantic classes are much less repetitive than atomic classes—and repetition assures better compression (Gzip).

In any case, it is also misleading to blame Atomic CSS for using many classes at once. For example, on Facebook, we can find markup like this:

<div id="contentCol" class="clearfix hasRightCol _5r-_ homeWiderContent homeFixedLayout hasExpandedComposer newsFeedComposer">

That’s 7 different classes, more than 90 characters!

If we compare the FAQ page of ACSS with the FAQ page of MaintainableCSS we can see that we have a delta of only 2 characters (average number of characters per class attribute)—in favor of the Atomic CSS architecture. Even though the FAQ page on seems more complex visually.

You can use this bookmarklet to check random pages yourself.

It Says Reuse Breaks Semantics

[…] then you encounter all the problems stated in the chapter about Semantics. Read that chapter now, if you haven’t already.

Below (between the 2 horizontal rules) is the Good and bad examples of class names section in its entirety:

Try and spot the difference between non-semantic and semantic class names…

<!-- bad -->
 <div class="red pull-left">
 <div class="grid row">
 <div class="col-xs-4">

It’s not clear at all what this HTML represents. You might have an idea of what these things look like (on small or large screens) but that is all.

<!-- good -->
 <div class="header">
 <div class="basket">
 <div class="product">
 <div class="searchResults">

Here I know exactly what I am looking at. I know the intention of what this HTML represents. And I have no idea how it looks—that’s what CSS is responsible for. Semantic class names mean something to both HTML and CSS (and JS).

To be honest, I think this speaks for itself; it demonstrates the opposite of what the author is trying to convey. Indeed, we have no idea how elements to which “semantic classes” are attached are represented.

Then there is this:

It is extremely rare, but there are times when it really does make sense to reuse a style. In this case use the comma in your selectors and place it in a well named file.

The comma is key here, it may help make things less crazy—but not by much; because the next advice is:

[…] if any selector deviates, even a little bit, then remove it from the common list and duplicate. You must be very careful with something like this. Do it for convenience, not for performance. Your mileage may vary.

I’m sorry, but I don’t see how this can be convenient or even efficient (performance wise).

It Says Something About Mixins

What about mixins?

I don’t know. How does that relate to Atomic CSS?

It Talks About Performance

I don’t have stats on hand, but I can very confidently say that it’s not wise to practice premature optimisation. Let’s say you have a very large CSS codebase (100KB or more).

I don’t think picking the right CSS architecture for your project falls into the “premature optimisation” category.

Also consider that one or two images are likely to be far larger than the entire CSS so exerting energy here is probably of little value.

The big difference is that styles sheets - unlike images - are blocking. So optimizing CSS may be the best thing you do in regard to performance and UX (perceived page load).

Final Thoughts

Atomic CSS is not for everybody. It is just a different way to tackle CSS—it comes with its own benefits and drawbacks. Understanding both will help you evaluate the tool. But criticizing it without knowing much about it—or even without really understanding what it is about—does not help the community. People should be able to make up their mind by reading decent material rather than being swayed by knee-jerk reactions on social media.

If the technique solves many of your problems without creating new ones then it should be a no brainer, but if you do not have the problems it solves then why bother?

This being said, I know by experience that “styling via markup” (à la Atomic CSS) benefits large code bases in which many teams are involved. If you can relate to that, then you may want to ponder the following (by Nicolas Gallagher):

When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy.

I think he nails it!

And what about this for “testimonial”?:

@thierrykoblentz A couple years of experience watching other approaches explode in size and then explode altogether at scale.

— Alex Lande (@alexlande) May 23, 2016