Atomic CSS

What is it?

Truly atomic design. Atomic CSS is a system of tiny, single-purpose, immutable presentational classes

They’re made for combination. Think of them as ingredients, which can be combined to make delicious dishes 🍩🍕🍰🍝

I’m red, underlined, and on the right!
        

I’m red, underlined, and on the right!

Food for thought?

Ingredients. Atomic classes are your ingredients

Pantry. An atomic library, like BassCSS or Tachyons, is a well-stocked pantry

Recipe. With this fixed, reliable pantry, you can cook all kinds of things (UI components)

Cookbook. A pattern / component library is a cookbook filled with recipes and variations; you can follow the recipes exactly or improvise with ease

For example

  
...

            

.someCard {
  margin-bottom: $space-1;
  padding: $space-2;
  background-color: $blue;
  border-radius: 3px;

  h2 { margin-bottom: $space-1; }
}
            

  
...

            

.mb1 { margin-bottom: $space-1 }
.p2 { padding: $space-2 }
.bg-blue { background-color: $blue }
.rounded { border-radius: 3px }
            

What problems does this solve?

Overhead. Building and maintaining good CSS is really hard and time-consuming

Incompleteness and bloat. New product feature ➡️ additional UI components or variants needed ➡️ more CSS added ➡️ repeat 😢

Complexity. The best CSS is the least CSS possible

Communication. It can be hard for designers and developers to speak a common language, and for anyone to understand unfamiliar CSS

Create new UI components with no new CSS (!!!)

Efficient. The stylesheet starts small and stays that way

Direct. No more writing (and rewriting) CSS

Expressive. Atomic classes can be combined to create a highly expressive array of new UI components without adding to or even opening a stylesheet

Never edit a stylesheet again. Never edit a stylesheet again.

Performant

BassCSS is 2.3kb (minified and gzipped)

USWDS 10.5kb, Bootstrap 23.7kb, Foundation 31.2kb (and these will only grow!)

smaller stylesheet ➡️ faster websites ➡️ happier users (and developers)

Developer velocity

Stop searching. No more digging through code to see what components are there and how they might change contextually

Stop fixing. No need to debug CSS when you’re not writing CSS

Naming things is hard

(and now unnecessary!)

Atomic calls ’em like it sees ’em

Predictable

"You had one job!" one class = one responsibility

Reliable. It's easy to predict what adding or removing a class will do

hi there!
        

Straightforward

Obvious. Simple, obvious classes are easy to pick up and use

Readable. You know what components will look like just by reading the markup

Reusable

Content classes are specific. They are necessarily scoped to the specific content element they describe

Presentational classes are universal. They can be used wherever the visual need arises

Encapsulation is your best friend

Stop worrying about specificity. Flat list of classes means no more worrying about global scope, specificity wars, overrides, descendant selectors

Easily refactorable. By encapsulating work in an individual block of html, it’s easy to refactor something with the confidence you aren't breaking anything else

Use components anywhere. In any context. Your UI components are now 100% portable

Beginner-friendly

Scrap the complexity. Writing efficient and robust CSS is tough

Democratize design. A small, fixed, descriptive system of classes simplifies the conceptual overhead, lessens the learning curve, and democratizes the design process 🇺🇸

Bring engineers and designers together

Nothing lost in translation. Designers can step in the code and engineers can influence design decisions

When everyone is speaking a common design language, deliverables are much more straightforward

Added bonus: the DOM is now a design tool

Doesn’t this makes the DOM ugly?

Design for the user, not the DOM. Sure, elements can and will have multiple classes and that’s a bit unconventional. But a) it doesn’t bother me, and b) who cares? (Not users.)

What if I have to change something on a hundred different pages?

Whoops! You may other problems. If this worries you, I'm worried about your templating architecture.

Stay DRY. If the markup for a component is defined multiple times across templates, don’t repeat yourself. The code should be consolidated to a single place.

How is this better than inline styles?

More comprehensive. Inline styles do not support media queries or pseudo elements

One to many. Inline styles are 1 to 1 for element styles, while a class has a 1 to many relationship

Flexible and fast. Atomic classes are faster to type and easier to read and can leverage the benefits of framework level variables (unlike inline)

Does this affect accessibility?

Nope! Presentational classes have no effect on HTML semantics

And please please please use well structured, accessible, semantic HTML

Great read: About HTML Semantics and Front-End Architecture, by @necolas

Aren’t you just moving complexity to the markup?

Yes! And that's OK!

It's more practical — it's easier for multi-developer teams to rearrange pre-built classes than perform CSS alchemy

Revisit "Encapsulation is your best friend" slide 😛

In the wild

Dogma is dangerous

And unnecessary. Instead of theoretical dancing-angels-on-the-head-of-a-pin debates, let's experiment and continuously evaluate and update best practices based on our core principle: user-centered decision making

All great truths begin as blasphemies.

Tip of the Hats

Dano Williams and Brian Hurst, for their keen eyes and helping hands in making this presentation more effective and sound more gooder

Brent Jackson and Adam Morse (& many other awesome devs), for everything they've built (and written about) around Atomic CSS

Hakim El Hattab, for making and open sourcing the super slick HTML presentation library I'm using here