Your browser may have trouble rendering this page. See supported browsers for more information.

|<<>>|73 of 273 Show listMobile Mode

Thoughts on Atomic/Utility CSS

Published by root on

The article In Defense of Utility-First CSS by Sarah Dayan on January 15th, 2018 (Frontstuff) is very long[1], so I’ve summarized a bit with notes and thoughts.[2]

I don’t really care about being pedantic without first knowing some facts. What are the requirements?

Requirements

  • Can I quickly make a precise change to a single component?
  • Can I make a global, thematic change?
  • How quickly can I make changes?
  • How maintainable is the result?

If atomic/utility CSS can deliver these things, then it’s probably a fine tool. But—spoiler alert—it seems more like a tool for designers—not programmers. Programmers have other, better tools for building CSS in a way that fulfills the requirements above.

Designers vs. Programmers

Essentially, these designers are like we programmers used to be: we used to care about cascading when we were still hand-coding our CSS. Now that we’re using LESS or another generator, we can use variables and functions for theming and use local CSS for precision. We can lean on specificity when it suits us and avoid it when it only gets in the way.

We want to declaratively say how we want everything to look and let our tools (LESS, WebPack with plugins) figure out how best to generate the CSS to accommodate supported browsers and also to create the kind of CSS that performs well without blowing up memory client-side. None of these optimizations and accommodations for targets should be up to the programmer/designer/CSS-writer at this point.

Utility vs. BEM

Utility-CSS feels functional, but it also feels like something you use when you don’t have LESS. I’ve never used BEM and agree that it never really made sense, from several good coding practices like DRY. That the author is coming from BEM to utility-CSS is not a surprise: BEM was never a good idea.

A Refactoring Use Case

“Early refactors are a pretty good indicator of unmaintainability.”

I don’t agree. It’s more a sign of shifting priorities or requirements. It’s not uncommon in agile development. The example the author has of changing the meaning of a “card” after there are already components using that style just means that you should make a “card2” class (not a “card-no-ribbon” one) because it’s just a different card type.

The problem is that the design now includes two cards, not that your implementation should somehow be able to easily roll with a confusing design.

Where I see a problem is when a card is supposed to have a certain padding and a border with a certain color (let’s say the “padding-top-8” and “border-bottom-lemon” from the author’s example). But then you don’t want those anymore.

Granted, with proper components, you’ll only have to change the style in one place anyway, right? So it doesn’t matter what you call it. You could have just called it “card” in the local styles and been done with it. So, either you have to remove those highly specific styles in many places in your HTML (as with an old-style web site, like earthli) or you change it in one place anyway (new-fangled, with React components).

Visuals vs. Semantics

I guess it’s the difference between knowing from the HTML what the component is going to look like (<blockquote class=“border-thick-left-red padding-left-medium font-navy”>) and knowing what the component is (<blockquote class=“newspaper”>).

The author writes:

“Yet, the bigger and the more complex a component gets, the less obvious it is to know what class name maps to what element on the screen, or what it looks like.”

But then they include an example where it’s absolutely clear which components do what:

<div class="entry">
  <h2 class="entry-title">The Shining</h2>
  <div class="widget widget-lead">
    <div class="widget-content">
      <p>His breath stopped in a gasp…</p>
    </div>
    <div class="author">
      <img class="author-avatar" src="…">
      <h3 class="author-name">Stephen King</h3>
      <p>Stephen Edwin King …</p>
      <div class="btn-group">
        <a class="btn" href="#">Website</a>
        <a class="btn" href="#">Twitter</a>
      </div>
    </div>
  </div>
</div>

I think this again shows the difference between programmers and designers: the code above is crystal clear to a programmer, so if a programmer is writing the CSS, then there’s no need to change anything.

The author seems to be a designer hell-bent on knowing exactly what the page will look like without actually showing it in a browser. I wish they’d included the version with utility CSS … it would have been a giant block of unreadable code, doubled in size with class names.

Don’t Change Anything

The author makes a good case for theming using CSS variables, which can be applied “at runtime” in the browser. The solution to theming with utility CSS turns out to be … making semantic styles instead of precisely named styles. So…not utility CSS.

The author references a few other articles, one of which is Kiss My Classname by Jeffrey Zeldman, which eloquently argues that there is nothing to change. He instead argues that developers and designers should use a visual style guide.

“I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

“Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.

“The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. (Emphasis added.)”


[1] It’s also almost two years old, but still seems to describe the state-of-the-nation in utility/atomic CSS.
[2]

Another article they referenced was CSS Utility Classes and “Separation of Concerns” by Adam Wathan on August 7th, 2017 and it’s even longer. It’s almost a jeremiad with the seeming intent of breaking the reader down with a flood of words. I could only skim it, but it seems like these people are styling without programming: that is, some of the utility classes and even the slightly semantic ones they use could very easily be written more cleanly if they just used component-local styles.

For example, this is completely unnecessary with local styles, because you don’t have to worry about specificity biting you in the ass:

<div class="media-card">
  <img class="media-card__image" 
src="https://i.vimeocdn.com/video/585037904_1280x720.webp" alt="">
  <div class="media-card__content">
    <h2 class="media-card__title">Stubbing …</h2>
    <p class="media-card__body">
      In this quick blog post and screencast, …
    </p>
  </div>
</div>

In another article On the Growing Popularity of Atomic CSS by Ollie Williams on November 24th, 2017, the author mentions that they’re addressing “n a mixed-ability team, perhaps involving backend developers with limited interest and knowledge of CSS”. I didn’t have the energy to finish that one either, because a skim indicated that it repeated a lot of what was in the article I did read.