[Feature Proposal] Group variants together to prevent cascade issues when multiple utilities set the same property

[benface]

Closely related to #660 (same problem, different solution... because the solution proposed in that issue wouldn't work here)

This is a problem I have in some of my plugins. Let's take my tailwindcss-gradients plugin for example. It can generate linear and radial gradient utilities, and both of these are different keys in the theme object, and they each have their own variants too. The problem is that they both set the same background-image property:

.bg-gradient-t-red {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00);
}
.bg-radial-t-blue {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}

So, if they both have the hover and active variants enabled, I would expect this to work:

<a class="bg-green hover:bg-radial-t-blue active:bg-gradient-t-red">...</a>

That is, I would expect the background of the anchor to change from a solid green color to a blue radial gradient when hovering it, and then to a red linear gradient when clicking on it. Unfortunately, that last part doesn't work, because variants are currently generated right after their associated set of default utilities:

.bg-gradient-t-red {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.hover\\:bg-gradient-t-red:hover {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.active\\:bg-gradient-t-red:active {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.bg-radial-t-blue {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}
.hover\\:bg-radial-t-blue:hover {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}
.active\\:bg-radial-t-blue:active {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}

Which means hover:bg-radial-t-blue has precedence over active:bg-gradient-t-red (same specificity, but defined later in the CSS).

I would like to suggest grouping utilities by variant instead, kinda like Tailwind is already doing with responsive utilities:

.bg-gradient-t-red {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.bg-radial-t-blue {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}
.hover\\:bg-gradient-t-red:hover {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.hover\\:bg-radial-t-blue:hover {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}
.active\\:bg-gradient-t-red:active {
  background-image: linear-gradient(to top, rgba(255, 0, 0, 0), #f00)
}
.active\\:bg-radial-t-blue:active {
  background-image: radial-gradient(closest-side at top, #00f, rgba(0, 0, 255, 0));
}

In other words, each variant would have its own "slot" in the generated CSS where all the utilities that have that variant enabled get generated in the variant's form.

Unfortunately it would break an existing feature which is the ability to customize the order of variants per plugin, but I wonder if anyone uses that behaviour? I feel like a variant should be able to give itself a position or a "priority" of some kind.

Thoughts?

[adamwathan]

In this case your issue is caused by having multiple addUtilities calls:

https://github.com/benface/tailwindcss-gradients/blob/master/index.js#L118-L119

If you add both sets of utilities with the same call, things should be grouped as you expect. The only issue is that it would break the ability for people to specify different variants for linear gradients vs radial gradients.

This would still be an issue if someone had a gradient plugin and another background image plugin though and wanted to switch between them somehow, though I'm not totally convinced it would show up as a problem in practice.

I think the general idea of all variants being globally grouped like responsive variants isn't a bad one but would take some time and effort to explore. It would be a breaking change either way unfortunately so would have to be slated for 2.0 which I don't intend to tag for a long time :/

[benface]

Hey Adam, yes I understand that it's caused by the multiple calls to addUtilities(), but like you said, I wanted to provide the ability to specify different variants for linear gradients and radial gradients (and soon, repeating linear/radial gradients).

I wasn't expecting this to be a quick fix or anything, but I'm glad you're open to the idea.

The way to customize the order of the variants could be similar to how we can customize the location of the responsive classes with @tailwind screens. In fact, they could all use the same syntax:

@tailwind base;

@tailwind components;

@tailwind utilities;
@tailwind variant('hover');
@tailwind variant('active');
@tailwind variant('responsive');

[benface]

@adamwathan Correct me if I'm wrong, but I think this feature proposal doesn't make sense anymore since #2651?