TailwindCSS `gotcha` with Prefixes and Pseudo State utilities.

tl;dr:
When you add prefixes to your tailwind config you might think that it prefixes every utility. Today I discovered that's not quite the case and I don't think that it's documented anywhere. For instance, when you apply a prefix (e.g. "u-") to your configuration you might expect to be able to use u-group and u-group-hover:. Tailwind does apply the prefix to the group utility but does not apply the prefix to the group-hover utility. So they would be used like this:

<div class="u-group">
    <div class="group-hover:u-some-utility">
    </div>
</div>

Extra Stuff

To be honest, the tl;dr is the majority of the blog post, but I figured i'd throw in some extra stuff and context fwiw.

Undocumented

I mention in the tl;dr that I "don't think" that this situation is documented anywhere. Looking back and carefully reading the tailwind docs I think that it might actually be documented but not explained as well as it could. Reading through the Prefix Section of the docs I read this:

That means that classes with responsive or state modifiers like sm: or hover: will still have the responsive or state modifier first, with your custom prefix appearing after the colon

which to me, I guess, makes sense as group-hover can be considered a state modifier but it could be better explained in my opinion. I'd think a lot of devs who are already familiar with CSS don't really read the docs word-for-word as they're blazing through their work so it could be a tiny detail easily missed by many devs.

Tailwind Prefixes

I imagine a lot of folks go with the default sans-prefix tailwind classes so this may not even be something for them to worry about. So you may ask, "Why even bother with utilities?".

If you were to build your website or app strictly with tailwind and no other CSS solutions then prefixes are irrelevant. However if you are like me, you enjoy using utilities where they make sense but also enjoy writing block-level stylesheets with a BEM (or similar) naming convention for more complex styling. When doing both, the classnames can become hard to read especially at a glance. Let's talk about prefixes or namespaces.

Imagine you're writing a component and using both BEM and tailwind. You're going to have quite a bit of classes in your markup. I don't think there needs to be an argument made to agree that sometimes tailwind classes (and more) can become hard to read, but there are ways to make it a bit better.

Let's review this tiny example:

<div class="someComponent flex flex-col items-center justify-start">
    <div class="someComponent__child flex my-10 p-4">
    </div>
</div>

Let's consider maintenance and coming back to a project in the future. This tiny example is easy enough to glance over and see which classes are BEM classes and which are tailwind. Now try to imagine a much larger file with potentially hundreds of classnames. It's also possible for another layer to be added such as compositions (check out CubeCSS) which adds to the already long list. This is where prefixes, or namespaces, come in handy to help us easily identify each type of classname when quickly browsing files and markup.

Let's review this example with prefixes:

<div class="b-someComponent u-flex u-flex-col u-items-center u-justify-start">
    <div class="b-someComponent__child u-flex u-my-10 u-p-4">
    </div>
</div>

Even with this small example it should be easier to tell which classnames are related to which style layer. The b- prefix stands for "block" which is part of CubeCSS. If you aren't using something like "compositions", you can use c- for "component". The u- stands for "utility".

One more small thing we can do to make it even a little more readable is separate the different style layer classnames by something like a pipe, or |, so that the markup would look like this:

<div class="b-someComponent | u-flex u-flex-col u-items-center u-justify-start | md:u-flex-row md:u-justify-between">
    <div class="b-someComponent__child | u-flex u-my-10 u-p-4">
    </div>
</div>

Conclusion

Hopefully this short post helps someone in the future. Whether it's with the particular issue mentioned in the beginning or expanding your CSS horizons with something such as BEM, prefixes or CubeCSS. Thanks for reading and I hope you have a great day!