[Suggestion] Better modifier ergonomics

[silicakes]

Given the following code

<input type="text" value="tbone" disabled class="mt-1 block w-full px-3 py-2 bg-white border border-slate-300 
rounded-md text-sm shadow-sm placeholder-slate-400
      focus:outline-none focus:border-sky-500 focus:ring-1 focus:ring-sky-500
      disabled:bg-slate-50 disabled:text-slate-500 disabled:border-slate-200 disabled:shadow-none
      invalid:border-pink-500 invalid:text-pink-600
      focus:invalid:border-pink-500 focus:invalid:ring-pink-500
    "/>

We can see that there's a multiple repetition of each modifier (:focus, :disabled, :invalid) as the syntax only allows passing a single class for each one.

My suggestion is to group the classes under a single modifier to make it more DRY in the following (or a similar) manner:

<input type="text" value="tbone" disabled class="mt-1 block w-full px-3 py-2 bg-white border border-slate-300 
rounded-md text-sm shadow-sm placeholder-slate-400
      focus:[outline-none border-sky-500 ring-1 ring-sky-500]
      disabled:[bg-slate-50 text-slate-500 border-slate-200 shadow-none]
      invalid:[border-pink-500 text-pink-600]
      focus:invalid:[border-pink-500 ring-pink-500]
    "/>

This, in theory, could also enable modifier chaining + class grouping in the following manner:

<input type="text" value="tbone" disabled class="mt-1 block w-full px-3 py-2 bg-white 
border border-slate-300 rounded-md text-sm shadow-sm placeholder-slate-400
      focus:[outline-none border-sky-500 ring-1 ring-sky-500]:hover[ring-sky-400]
    "/>

It is, in some senses, similar to what can be achieved using scss where a modifier can be nested within a block of previously declared modifiers:

.my-input {
  &:focus {
    outline: none;
    padding: 3rem 2rem;
    
    &:hover {
      border: 1px solid dodgerblue;
    }
    
  }
}

[wongjn]

There have been other suggestions about adding such a feature. The maintainers have addressed this request before, that you may wish to read up on if you have not already done so:

• A Twitter thread the creator of Tailwind, Adam Wathan
• A previous GitHub discussion thread with maintainer responses

[wongjn]

You can already add your own classes into Tailwind through the various extension methods, such as plugins or CSS. Content is your project so of course you can add that.

[silicakes]

Yes, but I'd like it to be dynamically added after matching with the markup mentioned above. Is that something that's possible with the current plugin ecosystem?

[wongjn]

You could do something like https://play.tailwindcss.com/D4ex5ghgKB

[silicakes]

Yes! you did it!
That's a great solution and people should be aware of it 👏

[sarimarton]

Wow, indeed. Bravo!!

[silicakes]

Thanks to @wongjn, I was able to create a small plugin to address this issue:
https://github.com/silicakes/tailwind-css-group-modifier-plugin

[adamwathan]

Meanwhile, hover:x-[cursor-pointer,bg-slate-400,text-white] would generate the following:

Just a small correction here — this would actually need to generate this:

.hover\:x-\[cursor-pointer\2c bg-slate-400\2c text-white\]:hover{
  cursor: pointer;
}

/* Other cursor utilities would go here... */

.hover\:x-\[cursor-pointer\2c bg-slate-400\2c text-white\]:hover{
  --tw-bg-opacity: 1;
  background-color: rgb(148 163 184 / var(--tw-bg-opacity));
}

/* Other background color utilities would go here... */

.hover\:x-\[cursor-pointer\2c bg-slate-400\2c text-white\]:hover{
  --tw-text-opacity: 1;
  color: rgb(255 255 255 / var(--tw-text-opacity))
}

/* Other text color utilities would go here... */

...otherwise you'd get surprising behavior when trying to override things. Basically you want the same effects to happen in the same order they happen when using just individual utilities.

So the CSS is bigger even without taking into account the increased odds of new unique classes being introduced 👍🏻

[mybearworld]

I just went off the plugin example wonjn commented, but yeah, if it were to actually work, that's true... so the CSS would grow somewhat exponentially there, adding a single class might need seventy new declarations for a large enough project. That's... not great.

[sarimarton]

@adamwathan This can be easily fixed by de-duping the selectors.

[BarakChamo]

@silicakes @wongjn this is great!

What would be a path to get this supported by IDE extensions?

[silicakes]

@BarakChamo IDEs should support this out of the box since it supports the native tailwind behavior 🙏

[sarimarton]

That's the argument people use for using vanilla CSS, and presumably there you disagree, or you wouldn't use Tailwind. How is this different?

Sorry, I'm not following. I'm using Tailwind, because it makes sense in the source code :) What I would disagree on with them, would perhaps their premise.

It's not particularly difficult to type hover: a couple of times, and it doesn't increase the size a whole lot

What's the argument here? Did I say typing "hover:" a couple of times hurts? It may? It may not? The app may have crosshair menus in the future, it may not?...

[mybearworld]

Interesting take... I thought "source" is kind of the opposite of "generated"... Maybe machine code is as much source code as C as well, right, we're literally just writing instructions and that stuff just gets auto-generated.

I'd agree there, and a big part of optimizing C (arguably the only part) is optimizing the resulting machine code.

I'm still struggling to follow this thought chain. I could argue that TW is better than regular CSS, but Tailwind is better for the CSS? Huh?

Terminology is a bit confusing here - I mean that Vanilla CSS < sm:x-[some,utility,classes] < sm:some sm:utility sm:classes

And where did I say that it warrants compromising my CSS quality by typing hover a couple times?

"I'm using Tailwind, because it makes sense in the source code :)" "The principle is not driven by CSS size, but by what makes sense in the source code."

Saying that some new things are bad because the current status quo is not ready for it is flawed argument.

That's correct, this was not a good argument. Still, when considering use of the plugin, that should weigh into the decision too.

[sarimarton]

and a big part of optimizing C (arguably the only part) is optimizing the resulting machine code.

Sounds like it's either a tautology or the words "optimizing C" lacks some explanation.

Terminology is a bit confusing here - I mean that Vanilla CSS < sm:x-[some,utility,classes] < sm:some sm:utility sm:classes

What's the connection in these three? How does vanilla CSS v. TW come here? We're talking about grouping, which is a question of DRY. You rightly pointed out that further iterations can change the course of what constitutes as DRY. Ungrouping might be needed. Might be not. Further iterations just as well can go in the direction which prefers not to ungroup. (I.e., running into separate situations rather than variations of one.)

And where did I say that it warrants compromising my CSS quality by typing hover a couple times?
"I'm using Tailwind, because it makes sense in the source code :)" "The principle is not driven by CSS size, but by what makes sense in the source code."

How are these in relation at all? What I said is that DRY aspects positively correlate with CSS size, so it's unnecessary to view it from an optimization angle.

Having said this, on a side note, purist voices which prioritize optimization above everything else are coming up all the time, and proven wrong all the time. I remember when it was widespread that you should use instance methods for onClick handlers in React, because inline arrow functions "get re-created all the time" and how much communication effort went into de-bunking this from the React team. Heck, we're in the Electron era.

Much more useful wisdoms here are these ones:

1. Everything is a trade-off
2. Don't fall for categorical "Don't do this and that" voices.

[mybearworld]

Further iterations just as well can go in the direction which prefers not to ungroup. (I.e., running into separate situations rather than variations of one.)

Grouping has the problem Adam Wathan commented on here, which means that the amount of rules you need for each class exponentially grows. My numbers are wrong, they are even larger for the grouping.

What's the connection in these three? How does vanilla CSS v. TW come here? We're talking about grouping, which is a question of DRY. You rightly pointed out that further iterations can change the course of what constitutes as DRY. Ungrouping might be needed. Might be not. Further iterations just as well can go in the direction which prefers not to ungroup. (I.e., running into separate situations rather than variations of one.)

CSS has the problems of not being DRY as well, which is partially also why Taillwind exists. You're getting rid of this aspect by grouping. With Adam Wathan's point, this is probably wrong, as you're still using utility classes - you'd have to write code like x-(text-white,bg-black) in order for the CSS to work.

How are these in relation at all? What I said is that DRY aspects positively correlate with CSS size, so it's unnecessary to view it from an optimization angle.

Of course, you don't need to unnecessarily optimize your CSS, but making sure you're not shipping CSS megabytes too big is important.

[sarimarton]

which means that the amount of rules you need for each class exponentially grows

There are multiple problems with this statement.

1. You're either repeating the variant prefix or the group selectors in the output, both have the same characteristics of repetition. Whichever is longer decides which is better to group to optimize. There's no "exponential difference".

2. What Adam Wathan shows at that link, and which is how this plugin works, is a suboptimal solution, for which this plugin can be righteously criticized, but this is a technical detail which can easily be fixed by using a postcss plugin which de-dupes the selectors. And you have a clear winner regarding point 1).

3. Having said this, I'm still not sure if it'd be worth worrying about unless the project reaches critical cost sensitivity. Maybe it's worth adding a note to this plugin that you might wanna include a selector de-duper.

CSS has the problems of not being DRY as well

What's the base of this statement? (I see now where your loose associations come from.)

DRY is when you're not repeating yourself. Grouping is a tool for achieving it. Ungrouping comes into picture when sub-parts of the group gets repeated elsewhere, so the possible gains start to shift. How does CSS have anything to do with this trade-off?

which is partially also why Taillwind exists.

That "partially" is very much a partially. Tailwind flourished before the JIT complier.

You're getting rid of this aspect by grouping.

Sorry, but total baseless claim. What you're saying can be reduced to "DRY is not DRY". Grouping is a trade-off.

but making sure you're not shipping CSS megabytes too big is important.

The fact that Tailwind flourished before the JIT compiler came about is also a good reminder of how marginal this is as an optimization question.

[mybearworld]

The fact that Tailwind flourished before the JIT compiler came about is also a good reminder of how marginal this is as an optimization question.

PurgeCSS was used and recommended. Just because sites didn't follow best practices doesn't mean it's good not to do it.

DRY is when you're not repeating yourself. Grouping is a tool for achieving it. Ungrouping comes into picture when sub-parts of the group gets repeated elsewhere, so the possible gains start to shift. How does CSS have anything to do with this trade-off?

I'm trying to say that you're worse off using grouping than if you used regular CSS.

[silicakes]

@mybearworld @sarimarton @adamwathan
So following up on your discussion, I see there a re good points for each side (though I personally lean towards @sarimartons arguments).

I was thinking that we can enjoy both worlds by creating a vite plugin of sorts where you can transpile the grouped syntax into a plain tailwind utility selector (modifier) just before tailwind gets to read your code:

import { parse } from "@babel/parser";
import * as t from "@babel/types";
import generate from "@babel/generator";
import { Plugin } from "vite";

export const groupModifierPlugin = ({ enforce } = {}): Plugin => {
  return {
    name: "vite-tailwindcss-group-modifier",
    enforce,
    load() {
      console.log("plugin loaded");
    },

    transform(code: string, id: string) {
      if (!id.endsWith(".tsx")) return code;

      const ast = parse(code, {
        sourceType: "module",
        plugins: ["jsx", "typescript"],
      });

      // console.log(t.traverse(ast, { enter: console.log }));

      t.traverse(ast, {
        enter(path) {
          if (path.type !== "JSXAttribute" && path.name?.name !== "className")
            return;

          const valueNode = path.value as t.StringLiteral;
          if (!valueNode) return;

          let newClassNames = valueNode.value.replace(
            /(\w+:(?:\w+:)*)x-\[([^]*?)\]/g,
            (match, prefixes, p1) => {
              const prefix = prefixes.slice(0, -1).split(/\):\(/);
              const classes = p1.split(",").map((c) => c.trim());

              return classes
                .map((c) => {
                  return prefix.concat(c).join(":");
                })
                .join(" ");
            },
          );

          valueNode.value = newClassNames;
        },
      });

      return generate(ast).code;
    },
  } as Plugin;
};

So essentially, it converts to the plain syntax AOT and you can have all the things.

I was able to implement a POC using safelist since I wasn't able to get in before tailwind did for some reason and didn't put too much time into that as I wanted to know whether you think its something feasible?

[amritk]

I was thinking about creating a vite plugin myself for this scrolling down this discussion!

[amritk]

Hey looks like one exists already, going to try it out

https://github.com/rschristian/tailwind-grouping#plugins

[sarimarton]

In the project I'm working on currently, there's no repetition at all:

print-shadow:apply-[w-[calc(50%-16px)],inline-block,m-2]

results in

.print-shadow .print-shadow\:apply-\[w-\[calc\(50\%-16px\)\]\2c inline-block\2c m-2\] {
  display: inline-block;
  width: calc(50% - 16px);
  margin:1rem;
}

This is exactly what I want.
(Sorry, it's not a minimal example, I'm just leaving it here. Plugins are below.)

  plugins: [
    plugin(function ({ addVariant }) {
      addVariant('print-shadow', '.print-shadow &')
    }),
    // Make grouping variants work
    // https://github.com/tailwindlabs/tailwindcss/discussions/11701#discussioncomment-6569866
    plugin(({ matchUtilities }) => {
      matchUtilities({
        apply: (value) => {
          return {
            [`@apply ${value
              .replace(/,/g, ' ')
              .replace(/ - /g, '-')
            }`]: {}
          }
        }
      })
    })
  ]

[mybearworld]

Okay, so your way of writing Tailwind is creating very large selectors instead of using JavaScript to handle those cases. Rewriting this in a more proper way should take away the need for these groups.

Raw media queries

First of all, you shouldn't be writing these raw media queries. Simply put them in your Tailwind configif you prefer working with max widths:

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    screens: {
      '2xl': {'max': '1536px'},
      'xl': {'max': '1280px'},
      'lg': {'max': '1024px'},
      'md': {'max': '768px'},
      'sm': {'max': '640px'},
    }
  }
}

This brings this down to:

  'lg:[:has(>*>&):has(~*)_&]:px-1',
  'lg:[:has(>*>&):has(~*)_&]:tracking-tight',
  'xl:[:has(>*>&):has(~*+*)_&]:px-1',
  'xl:[:has(>*>&):has(~*+*)_&]:tracking-tight',

Refactoring the has statements

The has statements are very hard to read, quite long, hard to refactor and don't work on Firefox. They also do not match your comment. Instead, you could add a group class and data-siblings attribute to the tab bar dynamically via JavaScript, and then check on this element via group-data-siblings:. Now, you'd have

  'lg:group-data-[siblings=1]:px-1',
  'lg:group-data-[siblings=1]:tracking-tight',
  'xl:group-data-[siblings=2]:px-1',
  'xl:group-data-[siblings=2]:tracking-tight',

Conclusion

And that's really a lot better, and also not that in need of an apply function.

[sarimarton]

I was waiting for you coming up with refactoring suggestions, but this a red herring, and your suggestions are debatable at least, if not plain wrong. Having said this, just for completeness (because, again, it's a red herring), let's break down your suggestions:

First of all, you shouldn't be writing these raw media queries.

That's another wrong "Don't". Pre-configured breakpoints are good for layout changes. In one-off situations where you have a specific case of adjusting widths (without layout change) when some specific elements appear, it's equally, if not more reasonable to use exact values, suggesting that the logic is pixel-optimized. Even when the values reflect pre-set breakpoints, the semantic variability there is not sm/md/lg/etc, but really exact values.

The has statements are very hard to read, quite long, hard to refactor and don't work on Firefox.

FUD. (The stakeholder doesn't care about Firefox, and seeing the nature of the issue, neither do I have any 'moral' concern about it.)

They also do not match your comment.

Elaborate? They work.

Instead, you could add a group class and data-siblings attribute to the tab bar dynamically via JavaScript

Sorry, but lol.

  'lg:group-data-[siblings=1]:px-1',
  'lg:group-data-[siblings=1]:tracking-tight',
  'xl:group-data-[siblings=2]:px-1',
  'xl:group-data-[siblings=2]:tracking-tight',

not that in need of an apply function.

It's a red herring in a red herring, but it is.

[mybearworld]

I was waiting for you coming up with refactoring suggestions, but this a red herring

So, according to you, refactoring is bad?

That's another wrong "Don't". Pre-configured breakpoints are good for layout changes. In one-off situations where you have a specific case of adjusting widths (without layout change) when some specific elements appear, it's equally, if not more reasonable to use exact values, suggesting that the logic is pixel-optimized. Even when the values reflect pre-set breakpoints, the semantic variability there is not sm/md/lg/etc, but really exact values.

Let me reformulate: "You shouldn't be using raw media queries in this context". Honestly, this would probably be a good case for container queries, but obviously these are very new and Tailwind doesn't support them too well. If the logic would be pixel-optimized you wouldn't be using rems in px-1 and tracking-light, but you are.

FUD. (The stakeholder doesn't care about Firefox, and seeing the nature of the issue, neither do I have any 'moral' concern about it.)

If you don't care about users or maintainability, then sure, that's a great way to do it.

Elaborate? They work.

They do, but if you ever reuse these classes in a similar context you may get problems down the line. Really, my whole argument is that while it may work now, it will cause problems later.

Sorry, but lol.

Why? It works and is much more stable. This is not the best solution im but without knowing more about the layout, this is the best you can do.

[sarimarton]

Below I've responded, but for completeness...

This suggestion:

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    screens: {
      '2xl': {'max': '1536px'},
      'xl': {'max': '1280px'},
      'lg': {'max': '1024px'},
      'md': {'max': '768px'},
      'sm': {'max': '640px'},
    }
  }
}

would override the default media prefixes, which would introduce a giant breaking change in the app. Furthermore, abstracting from a single case is a bad idea, this is almost the definition of overabstraction.

[sarimarton]

@mybearworld

The has statements are very hard to read, quite long, hard to refactor and don't work on Firefox.

https://tailwindcss.com/blog/tailwindcss-v3-4#new-has-variant

(Love when people with no prod experience try to be smarter on forums...)

[sarimarton]

So, according to you, refactoring is bad?

Why would it be bad? Do you know what a red herring is?

Let me reformulate: "You shouldn't be using raw media queries in this context".

It didn't get any better...

If the logic would be pixel-optimized you wouldn't be using rems in px-1 and tracking-light, but you are.

Lol. Pixel-optimized on the breakpoints. Why would I use pixel values for paddings? The media query values are highly context specific, specific to the fix number of tabs, their wordings etc, which might change upon requirement. In that case, it makes sense to adjust the pixel values (and keep it adjustable by using pixel values), and not figure out how to play with pre-set breakpoints.

If you don't care about users or maintainability, then sure, that's a great way to do it.

Strawman. Don't do this.

They do, but if you ever reuse these classes in a similar context you may get problems down the line. Really, my whole argument is that while it may work now, it will cause problems later.

While you're ignoring my counterarguments. Don't do this.

Why? It works and is much more stable.

You're overengineering.

[stephenhandley]

I've ended up just doing the following in js since I'm already using clsx and tailwind-merge to process tailwind classes:

import { clsx } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs) {
  return twMerge(twGroups(clsx(inputs)));
}

function twGroups(input) {
  const pattern = /([\w-]+):\(([^)]+)\)/g;
  return input.replace(pattern, (_, prefix, classes) => {
    return classes.split(/\s+/)
      .map((c) => `${prefix}:${c}`)
      .join(' ');
  });
}

> cn(`
...   flex min-h-[120px] w-full
...   px-3 py-2
...   border-l-1 border-input
...   bg-background
...   text-sm
...   placeholder:text-muted-foreground
...   focus-visible:(outline-none border-l-4)
...   disabled:(cursor-not-allowed opacity-50)
... `);
'flex min-h-[120px] w-full px-3 py-2 border-l-1 border-input bg-background text-sm placeholder:text-muted-foreground focus-visible:outline-none focus-visible:border-l-4 disabled:cursor-not-allowed disabled:opacity-50'

[silicakes]

Interesting take @stephenhandley, but contrary to other solutions, won't this run during runtime as well?

[Evertt]

@silicakes it seems like that to me yes, since the cn() function runs during run-time anyway. So then the question, I guess, is more about whether the performance overhead is significant or negligible.

Edit

I actually improved the regex a bit, because it wasn't working well with nested parentheses, for example when I wanted to do this:

cn(`after:(content-[attr(data-replicated-value)] hidden)`)

since attr(data-replicated-value) uses its own parentheses the original regex would stop matching after the closing parenthesis. The new regex can handle a single level of nested parentheses, which I believe is all you'd need. And also my new regex can handle multiple prefixes. It looks like this:

/([\w:-]+):\(([^)(]+(?:\([^)(]+\)[^)(]*)*)\)/g

Edit 2

Oh sorry, I just realized that TW doesn't actually parse these groups. I thought it did, but that's just because there were still styles cached from before I had tried to using the grouping functionality....

[juniorforlife]

Hi. Has there been any decisions on this? I believe variants grouping is a great improvement. Seems like there's already a working version here #11701 (reply in thread)

[wongjn]

As far as I am aware, the maintainers will not be including this as a feature. See #11701 (comment) for more details.

[juniorforlife]

That's sad. The biggest downside of Tailwind is long class names and this feature would significantly improve that :(

[sarimarton]

@adamwathan If the resolving logic of the variant groups went in the extractor, it would be possible to produce the same result as not grouping it, right? It could be merely a syntax sugar.

[wongjn]

That wouldn't work with regards to keeping Tailwind CSS language/framework agnostic, see #11701 (reply in thread) and #8337 (comment) for elaborations.

[BarakChamo]

This seems to be the most active thread discussing modifier and selector groupings, so I'm joining the discussion here after closing a new thread and being pointed here by @wongjn (thanks).

I've been catching up with the discussion both here and on Twitter on performance implications of groupings and some of the feedback from the maintainers on issues with relying on runtimes or potential need for source-code manipulation.

As this seems to be a much requested feature, and we would love to see something that combines that amazing power of new support for has:, *: and sibling and group selectors, I would love to get some more clarification on why a simple but effective implementation is still a potential performance or code size issue.

Let's take for example the classes applied in the blog post announcing support for has():

<label class="has-[:checked]:ring-indigo-500 has-[:checked]:text-indigo-900 has-[:checked]:bg-indigo-50 ..">
  <svg fill="currentColor">
    <!-- ... -->
  </svg>
  Google Pay
  <input type="radio" class="accent-indigo-500 ..." />
</label>

This component's classes are already getting a little unruly, but the goal is simple - apply a set of classes when the same set of modifier conditions are met:

• ring-indigo-500
• text-indigo-900
• bg-indigo-50

The first route is to apply separate classes, which results in the following code generated:

.has-\[\:checked\]\:bg-indigo-50:has(:checked){
  --tw-bg-opacity: 1;
  background-color: rgb(238 242 255 / var(--tw-bg-opacity))
}

.has-\[\:checked\]\:text-indigo-900:has(:checked){
  --tw-text-opacity: 1;
  color: rgb(49 46 129 / var(--tw-text-opacity))
}

.has-\[\:checked\]\:ring-indigo-500:has(:checked){
  --tw-ring-opacity: 1;
  --tw-ring-color: rgb(99 102 241 / var(--tw-ring-opacity))
}

Another way to achieve the same result is to use @apply on a named class:

.has-ring {
  @apply has-[:checked]:ring-indigo-500 has-[:checked]:text-indigo-900 has-[:checked]:bg-indigo-50;
}

The resulting code from this @apply rule is:

.has-ring:has(:checked){
  --tw-bg-opacity: 1;
  background-color: rgb(238 242 255 / var(--tw-bg-opacity));
  --tw-text-opacity: 1;
  color: rgb(49 46 129 / var(--tw-text-opacity));
  --tw-ring-opacity: 1;
  --tw-ring-color: rgb(99 102 241 / var(--tw-ring-opacity))
}

As you can see it is exactly the same.

Here is the Tailwind Play sketch with that same label styled both ways.

I understand that a more general implementation of grouping, as described by Adam on the Twitter thread, will result in redundant code from selector multiplication, but a restricted use-case, for example one where chaining is not allowed after grouping, would already afford huge DX benefits.

A simple example would be for the same rules (assuming a () based syntax):

<label class="has-[:checked]:(ring-indigo-500,text-indigo-900,bg-indigo-50)" />

Wouldn't this essentially be syntactic sugar for the same @apply?

This is illustrated manually in the Tailwind Play sketch by defining this named class:

.has-\[\:checked\]\:\(\ring-indigo-500\,\text-indigo-900\,\bg-indigo-50\)\ {
  @apply has-[:checked]:ring-indigo-500 has-[:checked]:text-indigo-900 has-[:checked]:bg-indigo-50;
}

I understand there are many other caveats when a feature like this is integrated into the larger project, but as I said I think even a limited implementation with reasonable restrictions, like requiring groupings are the last operators, to prevent exponential code generation would be a massive readability and DX boost.

While this is possible through extensions, native support would surely be more performant, less prone to issues and easier to integrate with IDE tooling such as autocompletion and conflict detection.

[Evertt]

Now that TailwindCSS is being largely overhauled with version 4.0, does that change anything about the arguments against including this as a built-in feature within TailwindCSS?

Because as many have pointed out before. It would greatly reduce the visual noise when reading code and help make things more DRY which I also believe would help make things more maintainable.

[MrOxMasTer]

so, after reading this thread, which has been going on for two years, I've come to a couple of conclusions.

And the problems are as I realised only in what the group will be compiled into, but also I wanted to point out the UX component of using such groups and their approaches.

Here's a list of plugins that people have made and suggestions, with my discussion:

1. Multi-
   https://github.com/brandonmcconnell/tailwindcss-multi?tab=readme-ov-file#new-syntax-explanation

As I understand it, this is one of the oldest and most popular works on this topic, because it even touched on changes to a certain version of tailwindcss.

<div class="hover:multi-['bg-red-500;text-white']">...</div>

In my opinion this is a totally messy and awkward syntax, in addition to having to write an extra utility (multi-), you also have to write ‘ and ;

About the implementation internally:
I assume made based on @apply, like many suggestions here: https://play.tailwindcss.com/D4ex5ghgKB

2. apply- @silicakes
   https://github.com/silicakes/tailwind-css-group-modifier-plugin

<input type="text" value="tbone" disabled class="mt-1 block w-full px-3 py-2 bg-white border border-slate-300 
rounded-md text-sm shadow-sm placeholder-slate-400
      focus:x-[outline-none,border-sky-500,ring-1,ring-sky-500]
 disabled:x-[bg-slate-50,text-slate-500,border-slate-200,shadow-none]
 invalid:x-[border-pink-500,text-pink-600]
 focus:invalid:-x[border-pink-500,ring-pink-500]
 "/>

A better option. Without ' and with the ability to change the prefix to the one you want.

I like this idea too and it epitomises the point.

Inside: as I understand, also made on the basis of @apply.

What is the problem @apply: As far as I understand, you have a separate class generated for each situation, with all the @apply ...

So it will be something like this:

.apply-[...] {
 @apply ...
}

.apply-[...] {
 @apply ...
}

If I have misunderstood how tailwindcss works in this situation - please comment for me

3. twGroups - @stephenhandley

A good option, on par with content.transform
But it has a fat disadvantage - it works at application runtime.

This is not a good way and considering that not for every cn() function is set.
And if cn() function is used for everyone, it will load the application heavily

import { clsx } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs) {
  return twMerge(twGroups(clsx(inputs)));
}

function twGroups(input) {
  const pattern = /([\w-]+):\(([^)]+)\)/g;
  return input.replace(pattern, (_, prefix, classes) => {
    return classes.split(/\s+/)
      .map((c) => `${prefix}:${c}`)
      .join(' ');
  });
}

4. content.transform - @milamer
   https://github.com/milamer/tailwind-group-variant

In my opinion this is the best realisation.

Syntax: convenient, nothing superfluous
Internals: Works exactly the same as standard tailwindcss and doesn't break anything, but affects only slightly longer compilation time of tailwindcss, which is likely to be insignificant

Before:

<div className={'relative z-10 pb-8 bg-white sm:pb-16 md:pb-20 lg:(max-w-2xl,w-full,pb-2) xl:pb-32'}>
      {children}
    </div>

After:

<div className="relative z-10 pb-8 bg-white sm:pb-16 md:pb-20 lg:max-w-2xl lg:w-full lg:pb-2 xl:pb-32">
      {children}
 </div>

The only thing: , can be removed as it is inconvenient and Space is convenient and quick and always has your finger on it. Especially we have a restriction going ( )

P.S About the ‘what it will compile into’ issue - what some people want it to be as a single class after compilation - this is really expensive (will grow every time), so the best solution for now is to stick with the option that tailwind suggests