Jan. 5, 2021, 11:16 p.m.

CSS as a Utility

Known Unknowns

In her 2019 dotCSS presentation, Sarah Dayan makes the case for creating Utility-First CSS.

Utility-first CSS focuses on creating classes that describe how something should be rendered in the browser, rather than creating a class to represent the component being rendered and attaching all of the CSS code required to the class for that component.

For those already familiar with this strategy, it is how Tailwind CSS was designed. I haven't had the opportunity to use Tailwind, and frankly it was low on my list to learn for some reasons I'll outline below.

First, a comparison of the traditional "component" way and the "utility" way:

The Component way

HTML:

<div class="card">
    <h3>This is the card</h3>
    <p>This is some content.</p>
</div>

CSS:

.card {
    background-color: #333333;
    border: 1px solid #cccccc;
}
.card h3 {
    color: #ff0000;
    font-size: 16px;
}
.card p {
    color: #ffffff;
    font-size: 12px;
}

The Utility way

HTML:

<div class="bg-dark-gray border-gray">
    <h3 class="medium-text">This is the card</h3>
    <p class="normal-text">This is some content.</p>
</div>

CSS:

.bg-dark-gray {
    background-color: #333333;
}
.border-gray {
    border: 1px solid #cccccc;
}
.medium-text {
    font-size: 16px;
}
.normal-text {
    font-size: 12px;
}
.text-red {
    color: #ff0000;
}
.text-white {
    color: #ffffff;
}

But it's ugly

To me, the Utility CSS method seems ugly. There's a pile of classes added to each tag I want to style. It reminds me of inline css. It feels, in this short, contrived example, that there's so much more CSS that needs to be written.

Actually it's performant

With zipped data going down the tubes from the server to the browser, the long lists of classes aren't a bottleneck. The repetition doesn't add size to the files sent.

Actually it's maintainable

Maintainability is the biggest reason I see for moving to a utility-first CSS model. In my example, I may not need a card anywhere else on the site, but I may have another component similar in style. I would not want to tie these two components together via CSS, though, so I would duplicate most of the CSS for both objects. Now my CSS is getting bloated.

In the future, I might remove the card component from the site. Unless I'm very diligent, I might forget to remove the corresponding classes from the CSS. Further on in the future, I will be afraid to remove the card CSS because I no longer know where it is being used.

With a simple and clear design system, I am reusing smaller chunks of CSS. Deleting a component requires no real changes to the CSS. Those utility classes are used all over, so they wouldn't get deleted anyway.

Summary

I see a real advantage to shifting my perspective on utility-first classes. It will really fix some of the nightmares I've had getting sites looking right across the board. I'll be looking into Tailwind CSS as well.

You just read issue #31 of Known Unknowns. You can also browse the full archives of this newsletter.

This email brought to you by Buttondown, the easiest way to start and grow your newsletter.