Things to rethink with Tailwind CSS — Part 2: Colors

As you may already know from Part 1 of my series “Things to rethink with Tailwind CSS”, I’ve been involved in web development for more than a decade and have seen many trends, technologies and approaches come and go.

Of course, people like to be fascinated by new things because it offers exciting, new possibilities, because it makes things easier, or just because it breaks the old familiar boredom... And I admit, Tailwind CSS triggered those very feelings in me. Of course it did!

Well aware of this initial euphoria, I have now been dealing with it intensively for many months. And what can I say… Working with Tailwind CSS still fascinates me! Some approaches and ways of thinking become obsolete, others change in a healthy way, not only improving my workflow as a programmer, but also improving the quality of the web application itself.

So… Welcome to part 2 of my series “Things to rethink with Tailwind CSS”, in which I want to give you some insights, tips and suggestions on how to work with Tailwind CSS.

Photo by Robert Katzki on Unsplash

Introduction

In case you haven’t heard of Tailwind CSS yet I would like to provide you with the link to the official website below:

Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.

It’s a CSS framework that contrasts with frameworks like Bootstrap and co. due to its utility-first approach. The implementation of layout/design in HTML is done by composing various CSS classes directly in the markup. Once familiar with it, web apllication frontends can thus be realized very quickly and with less risk for side effects.

Part 2: Colors

By default, Tailwind CSS already provides a huge palette of colors. Please see the official documentation. The abundance of colors provided is ideal for developing a PoC quickly and without much configuration effort. Simply outstanding!

Excerpt from the color palette of Tailwind CSS

Thanks to the comprehensible and clear naming, colors can be conveniently used, coordinated with each other and easily exchanged if necessary. And because Tailwind CSS compiles only those CSS classes that are actually used in the markup, there is no unused CSS code at all. So basically there is nothing to complain about. Isn’t it?

Well… for simple websites or quick PoC’s this may certainly all be purposeful and goal-oriented. But what if we are in a more complex context? For example in an e-commerce project, where a team of developers is working on and where also a certain corporate identity has to be maintained?

That leads me to say that there are certain risks involved here:

1. Due to the large number of colors and shades, there is a great risk that a developer might get the wrong shade and thus create wild growth. This may violate the corporate identity! In addition, this can increase the effort for maintainability or interchangeability.
2. All the out-of-the-box colors and shades are available in Tailwind CSS by default for text colors, background colors, border colors, stroke and fill colors, shadow colors, etc. Who is supposed to keep track of everything in a large project and a team of developers?
3. Last but not least, imagine how long it takes to constantly pick the right color out of this vast number of possibilities. This not only slows down the workflow, but also wastes precious time.

And because all this is not enough, you can also configure more colors as you wish. Colors in excess!

// tailwind.config.js

module.exports = {
  theme: {
    extend: {
      colors: {
        primary: {
          DEFAULT: '#17275c',
        },
      }
    },
  },
}

My recommendation: Rethink color configuration

Assuming that you are provided with a layout by the designer, this usually already results in a concrete color palette anyway. Main colors, color variants, frame colors, text colors and so on can be defined concretely and can in principle also be used as a basis for the color configuration of Tailwind CSS.

Custom colors at all
So instead of using extend to unnecessarily expand this huge set of default colors, it is a good idea to completely replace the color configuration of Tailwind CSS and only configure colors that are actually needed in the project.

// tailwind.config.js

module.exports = {
  theme: {
    colors: {
      primary: {
        DEFAULT: '#17275c',
      },
      ...
    }
  },
}

This not only makes it much easier to find the color you need, you can be sure that you have made the right choice and you can adjust the color code (in the example as HEX code) at a specific point if necessary and thus apply this change to the entire project.

Color names for the win
Another thing that has proven to be a boon for me over the past few months is the correct naming of colors. Hand on heart — who has also used “primary”, “secondary”, “warning”, “danger” and so on in the past years ? In a sense, these designations were already “speaking”. Nevertheless, I often had the feeling that these somehow often slip away from me, especially in larger projects, and I seem to lose the reference to them. Especially when then also designations like “grey-dark”, “grey-mid”, “grey-light” or so were added. This can get really confusing, right?

The remedy is to think about sensible, abstract but still clearly understandable designations beforehand. Designations that fit the context but are not so specific that the color code behind them cannot be exchanged anymore.

Suppose we have a website with a light background and dark text on it. The footer, for example, should then have a dark background and light text. Which color values are “light” and “dark” in concrete terms is not really important. So we could say that we define two colors:

// tailwind.config.js

module.exports = {
  theme: {
    colors: {
      light: "...",
      dark: "...",
      ...
    }
  },
}

The corresponding HTML markup could look like this:

...
<body class="bg-light text-dark">
  ...
  <footer class="bg-dark text-light">...</footer>
</body>
...

Now, however, the website is also to get a dark mode. No problem! Just change the color codes behind the color names and you’re done. Um… stop! Not so fast! Is that correct in terms of content now? We declare the body tag with the CSS class “bg-light” and then have a dark background instead of a light one in dark mode. Strange, confusing and just not correct!

Hopefully you realize that the color designations just don’t work for this use case. As I mentioned above, it is important to find terms that are abstract enough but still have enough meaning that a developer understands what is behind them when using them.

I will show you below a variant that works better for the use case. But first I want to talk about the topic “Configuration Sections” in Tailwind CSS.

Colors specific to each use case
The Tailwind CSS configuration is divided into so-called sections. A few examples are: colors, fontFamily, spacing, borderRadius, … (please check out the official documentation). So far in the code examples above, I have always made changes in the “colors” section. All colors that are in this section are automatically available as text colors, background colors, frame colors and so on.

However, one has the possibility to configure colors so that certain ones can be used only for text colors, others only as background colors, and so on. So if I take the example from above, the problem with the color labels in combination with the Dark Mode can be solved as follows:

// tailwind.config.js

module.exports = {
  theme: {
    backgroundColor: {
      normal: "white",
      inverted: "black",
      ...
    },
    textColor: {
      normal: "black",
      inverted: "white",
      ...
    }
  },
}

...
<body class="bg-normal text-normal">
  ...
  <footer class="bg-inverted text-inverted">...</footer>
</body>
...

Brief explanation: First, I separate background and text colors in the configuration. Then I define the background colors “normal” and “inverted”. This way the developer immediately recognizes that the footer for example has a background color that is defined contrary to the background color of the body. And I do the same with the text colors, with the difference that the color code of the text colors is per se contrary to the respective background colors (That’s why I have now also deposited “white” and “black” in the example, so that it is more understandable).

If I now exchange the color codes behind the color labels so that I can display the website in dark mode, the labels — or more precisely the resulting CSS classes — are still correct.

Conclusion

In conclusion, thanks to the Tailwind CSS configuration, it is possible to define colors specifically per use case in such a way that the developer has only a limited set of options, which in turn speeds up the workflow and reduces the risk of incorrect color values within the fixed framework of a corporate identity.

If you also use cleverly chosen color designations, you benefit twice! Because the more comprehensible they are, the easier it is for a developer to get to grips with the project and thus reach his goal more quickly. In addition, color codes can be easily replaced afterwards without having to adapt the HTML markup or risk that CSS classes no longer match the actual truth — the color values.

Hope you enjoyed this post, thanks for reading and have fun!