How I Learned to Stop Worrying and Love the Atomic Class

The first conversation I had with Cap about using atomic classes at BuzzFeed went something like this:

Cap: Check out basscss. It’s a class library that lets you build new UI elements quickly.

Sam: I hate it!

Basscss is an atomic class based CSS library created by Brent Jackson. A very good one! But I really hated it at the time. But I don’t hate it anymore! Atomic classes are the backbone of Solid, BuzzFeed’s CSS styleguide. With my blessing.

How did that happen? Well I took a journey of self-discovery. Along the way I learned that an atomic class system can be a rad tool in your design/development arsenal. If you use it right. Take my hand and I’ll lead you there. We’ll learn a lot along the way. And, if we’re lucky, have a few laughs ;)

What Are Atomic Classes?

Atomic classes are tiny, single-use CSS classes that you can combine to style HTML elements. For example in Solid the class “.xs-p1” will give you one unit of padding. Atomic class libraries give you a suite of these classes. You can combine them to tweak elements or style them from the ground up. Here is an example of an element styled with Solid’s atomic classes:

<div class=”xs-border xs-p1">10 top thought leaders</div>

When I first saw a string of code like that it terrified me. I believed we should write CSS classes that describe their context rather than what they look like. I believed that well-written HTML will let you totally change a site’s visual style by switching up its CSS. Here is that same element with a semantic class name:

<div class=”subheader”>10 top thought leaders</div>

Plus the following CSS, in a CSS file somewhere.

.subheader {
  border: 1px solid rgba(0, 0, 0, .2);
  padding: .5rem;
}

I feared deviating from these nicely named CSS classes would open the door to total DOM chaos: swaths of tiny classes in massive template files. Fire. Brimstone. I researched every point and counterpoint I could find on atomic class systems. I even made 30 minute powerpoint presentation titled “Systemic Vs Atomic Class systems.” It was so dry it nearly mummified the team.

After much research and tinkering I realized that we shouldn’t choose the CSS framework that was more ideologically “correct.” We should choose what is correct for BuzzFeed. So the Solid team picked apart BuzzFeed’s needs and goals and developed a CSS framework that works for our team. One that uses atomic classes!

Why Atomic Classes Work for BuzzFeed

The indisputable greatest strength of an Atomic-class-based system is it allows you to construct new, responsive UI quickly with no additional CSS. It is Ultra Dry™. Its greatest weakness is it makes the DOM very difficult to read.

In order to understand why this tradeoff can be worth it you need to download Solid and, as a designer, start building UI. As a developer the ability to choose how many units of padding a container has feels like a burden. But as a designer being able to rapidly tweak and deliver finished UI is incredible. You can use the DOM as a design tool.

At BuzzFeed we are designing new UI all the time, across projects. We cannot definitively say that BuzzFeed’s UI is built on a foundational `box` element. But we can define what our border colors and padding units will be and give our designers the autonomy to take it from there.

Autonomy is the key word here. Previous style guides I’ve worked on have been super rigid. Here is an element, don’t mess around with it. Solid is not like that. It’s a toolkit. We’re assuming anyone using Solid has the sense to make both strong design and markup decisions. We back that up by training our design team in HTML and CSS best practices, involving them in code reviews, and pairing them with developers.

Now we have designers writing production ready templates across projects, using a single framework, with no CSS bloat. Thanks, atomic classes :’)

Sam’s Golden Top 4 Very Special Rules For Using Solid’s Atomic Classes!

If you’re not careful with atomic classes you can make your HTML illegible and tie style to content in murky ways. To prevent that follow these rules.

1. Atomic classes can only be overwritten by other atomic classes.
   If you can’t trust that an atomic class’s style is applying the whole system is worthless.
2. Atomic classes can never be added or modified by JavaScript.
   You should be able to add/remove classes without breaking functionality.
3. Name your template files well & add descriptive comments.
   To compensate for all of these small style-based classes.
4. If you are fighting against Solid classes take a deep breath and rethink your approach.

Print these rules out on the brightest color paper you have, glue them to a cereal box, and leave it on your desk for reference.

What a Team Wants, What a Team Needs

this is the laugh I promised!

I’m not saying you should drop what you’re doing and follow our approach; the CSS framework you choose should depend on the needs of your team. If you want a rigid system of elements with little style variation you might want to make a component library from scratch. If you don’t need to control the visual style of your app try bootstrap/foundation.

We needed a front end toolkit that lets us design/build new UI quickly. We rolled our own, and now we use it all the time. And you can too! Download Solid, make something with it, and let us know what you think. You might want to build something similar. And remember: you are beautiful, no matter what they say.