The Shorthand-Longhand Trap in Auto-Generated Atomic CSS

Atomic CSS is an intriguing output target for build-time tooling: one class, one job. But as Robin Weser explains, the path from authored styles to atomic classes has a nasty edge case when shorthand and longhand properties mix. Specifically, if you write both margin: 10px and margin-top: 5px, the generated classes can collide in the cascade, producing the wrong result.

Fela, Styletron, React Native Web, Otion, and StyleSheet all fall into this camp—they take familiar, monolithic CSS-in-JS syntax and produce atomic classes at build time. Each property-value pair is rendered once, cached, and reused. That’s the whole appeal: you get the performance profile of atomic CSS without hand-authoring it.

What You Get From All-Atomic Styles

Going all-in on atomic classes means shipping dramatically less CSS. Because no property-value pair is ever repeated and there are no bespoke authoring class names, an atomic stylesheet trimmed to actual usage can be a quarter the size of a hand-authored one—or less. CSS is a blocking resource, so that matters.

There are other wins: you never have to name a class, design consistency comes free if you limit the class pool, and some developers simply find the workflow faster.

The Manual Approach Still Exists

Nothing stops you from writing atomic CSS by hand. GitHub does this with Primer, and Facebook did it for FB5—though mega-corporation precedent is not a recommendation. Tachyons is the original big pile of opinionated classes you can grab and use as-is.

Tailwind is the dominant player in this space, and it adds real value beyond a class collection:

  • It's configurable—you decide what the classes do.
  • It encourages purging unused classes, which is essential to getting the bundle-size benefit.
  • It ships a UI library for quick starts.

Yahoo was an early experimenter too, with a system that processed function-like class names (e.g. class="P(20px)") into real classes during a build step.

The Build-Time Sweet Spot

Writing atomic CSS by hand is a developer-experience tradeoff that many find unacceptable. The alternative is to let the tooling do it. Weser puts it plainly: this is the only reasonable way to use atomic CSS, because it doesn't change how you write styles. Style9, covered previously on CSS-Tricks, takes the same approach.

The concept has legs. The five libraries above all implement it, and it makes sense that they're CSS-in-JS based—the system must process both the markup and the styles together, which is exactly what CSS-in-JS tooling is built for.

If the computer can convert authored CSS into atomic classes during the build, you get production performance without authoring pain. Each class is rendered only once and then reused from cache—a model that works because the tooling controls the entire pipeline.

The shorthand-longhand problem is real, and it's the kind of edge case you only discover when you actually build such a system. That it exists doesn't undermine the approach—it just means the tooling has to be smarter than a naive one-class-per-declaration generator.