Back to Sass and traditional CSS

July 8th, 2024

I'm currently working on a project that doesn't use any atomic or utility-first CSS.

It uses Sass, which I haven't used for some time, but it has reminded me of some of the reasons I like the utility-first approach to CSS.

Specificity and cascading

With utility styles, there are no specificity or cascading issues as styles are added to each element and provide a local scope.

With global styles, your element can be overridden or altered by another part of CSS elsewhere in the stylesheet.

I've also had situations where I've had to "undo" unwanted styling that was added elsewhere, such as on a hover or focus state.

Easier to read and understand

With utility styles, I can read the classes on an element and understand straight away what styles are applied to it and start to make changes - especially when using a framework, such as Tailwind CSS.

With generic class names or IDs, I'm not able to do that.

Context switching

To make changes to an element, once I've found it in the HTML, I then need to find the stylesheet (or stylesheets) that add the styling and switch between the HTML and CSS files as many times as needed.

Usually with utility styles, I rarely need to edit the stylesheet and can work almost exclusively in the HTML and not need to switch between files.

Concatination and nesting

Something I've avoided with Sass, as well as newer versions of CSS, is the over-use of nesting styles, which makes it harder to find them when searching for the correct stylesheet.

If there was this CSS:

.sidebar {
  &-wrapper {
    a {
      &:hover,
      &:focus {
      }
    }
  }
}

If I tried searching for .sidebar-wrapper or .sidebar-wrapper a:hover, they wouldn't be found and it would take me longer to find it.

Here's the thing

It's taken me a while to get back into this way of working with CSS, but it does remind me why I prefer to use utility styles for my own projects.

- Oliver