Grouping variants together

[siamekanto19]

It would be great if we could group the classes used inside classes based on their variants. Now if we want to change two styles on hover state, we have to write hover:bg-red-500 hover:text-white and so on. It would be great if we could group these styles together for hover state so we could write something like hover:(bg-red-500 text-white). We could group all other states like that too. It would really make the developer experience a lot better. Some other frameworks like WindiCSS, UnoCSS are already doing it. It would be great to see this in Tailwind too.

[randallmlough]

Huge +1 for this. Grouping would make reading tailwind classes so much easier. IMO readability goes down exponentially the more classes and variants of those classes gets mixed together.

Twin Marco does a great job of grouping and even sub grouping. I would love to see this incorporated into tailwindcss natively

EDIT: after reading the Adam's twitter thread I see they've researched this issue extensively. Hoping one day it becomes an addition without performance issues

[tsathis]

References: Variant Groups in WindiCSS

[milamer]

I wrote a transformer that parses the files before tailwind uses them to spread the grouped variants into single class names. This should remove the increased css bundle size.
The drawback is that you have to wrap your class names into a spread function that will spread the variants increasing the runtime.

tailwind-group-variant

const expandVariant= createTransformer({ separatorChar: ' ' })
expandVariant('lg:(max-w-2xl w-full pb-2) xl:pb-32')
// lg:max-w-2xl lg:w-full lg:pb-2 xl:pb-32

// tailwind.config.js
const createTransformer = require('tailwind-group-variant')
module.exports = {
  content: {
    files: ['./app/**/*.{ts,tsx,jsx,js,mdx}'],
    transform: createTransformer({ separatorChar: ' ' }),
  },
  ...
}

[Nefcanto]

The argument Adam made on Twitter is one of the worst arguments a developer could make.

I fail to understand why they did not consider separating grouped classes first and then compiling them.

This simple idea came to the mind of @milamer and I also thought about it. This should be very very easy, right?

[RobinMalfait]

Please do not assume that other people have "the worst argument", if you don't know the full story and don't know all the trade-offs.

---

The argument Adam made on Twitter is one of the worst arguments a developer could make.

This can be explained by your next sentence:

I fail to understand why they did not consider separating grouped classes first and then compiling them.

It's not that Adam is making "the worst argument", it's that you don't understand why there are limitations to this problem. And that is totally fine, I just want to give you some context about the trade-offs and issues in general so that you can change your "very very easy" statement to something like "oh I see".

Tailwind CSS is currently a build-time compiler that at the end of the day generates a CSS file based on your content files. If you use a class like this: md:(font-bold,underline) behind the scenes we would generate md:font-bold md:underline and then replace the selector again with your original selector.

Why is that you may ask?

Well, if we just compile to:

.md\:font-bold {}
.md\:underline {}

Then not a single selector matches the selector in your template. This means that no styles will be applied. To fix this there are a few solutions:

1. The solution we currently have, by replacing the individual rules with the selector you have in your template files.
2. Mutate source/generated files.
3. Introduce a (JS?) runtime.

I know you are hinting at the solution from @milamer which is a good solution and it works by:

1. introducing a JS runtime (expandVariant function)

This is fine for JS based projects and as long as the expandVariant isn't too expensive there should not be any (performance) problems (but please still measure if it is the case!). But we don't want to ship runtime code when it can be solved without runtime code. It isn't as expensive as some CSS-in-JS tools, but they have different trade-offs. However, there are products like Maizzle that use Tailwind for email templates where it is impossible to run JavaScript and therefore also impossible to ship a runtime.

You are also hinting at "I fail to understand why they did not consider separating grouped classes first and then compiling them." we could do that, but then you have to rewrite source files (otherwise your selectors won't match), so all of a sudden you have to deeply integrate with your bundler (if you even use one).

This comes with its own problems, because Tailwind doesn't only work with HTML/JS based projects, it works with a bunch of programming languages and frameworks. You can use it in PHP, Ruby, Elixir, Rust, ...

If we introduce something that can replace source code, then we have to have knowledge about all these programming languages to ensure it is safe to replace some code.

Even in HTML/JS, there are some problems:

<div class="md:(font-bold,underline)"></div>

This might look easy, we can just find / replace.

How about comments?

<!-- md:(font-bold,underline) -->
<div class="underline"></div>

Do we need to replace those? No? Well, now we need to ship an HTML parser so that we can know about what parts are safe to replace and which parts should not be touched.

How about JS variables:

const myVariable = 'md:(font-bold,underline)'
<div className={myVariables}></div>

How do we know that it is safe to mutate that myVariable variable? We would need yet another parser and know where the variable is used, know that it is used in the className, know about its scope to know that it is safe to mutate those.

But what if you call some function:

const myVariable = myFunction('md:(font-bold,underline)')
<div className={myVariables}></div>

We don't really know what myFunction does. Is it safe to change md:(font-bold,underline) to just md:font-bold md:underline? We don't really know. Maybe it is statically analysable maybe it is not, it will highly depend on the project and on what myFunction does.

What else can we do? Well, we can think about some heuristics and only make it work for the cases we are 100% sure about that it would be safe. This is fine, but then you will run into situations where it works in some scenarios and not in others and you will have a very hard time trying to debug what's going on here.

Another common solution is to introduce something like:

let classes = tw`md:(font-bold,underline)`

Where the tw can act as some marker where we know it is safe to use. However, this would only work in JS based projects not in projects with different programming languages like PHP, Elixir, Ruby, Rust, ...

---

So at the end of the day, if you want to introduce a runtime in your project by creating an expandVariant function or similar like @milamer described, by all means do it if it works for you. But I hope you understand why we can't "bake it in" because it is "very very easy" because it is simply not "very very easy".

[Nefcanto]

@RobinMalfait thank you so much for taking the time to explain in detail and my apologies for being harsh.

However, I still think that there is a very very easy way to do this.

Please let me explain.

As you mentioned, Tailwind is a build-time tool. Let's review why we use build tools in the first place.

Why do we use build tools? To build codes we write.

Just the way TypeScript is complied/transpiled to JS, Tailwind can replace md:(text-red-500 font-bold) with md:text-red-500 md:font-bold in the output, not in the source code.

This means that my source code is not changed at all, but inside the browser's dev tools, I will see the expanded version of my classes.

• This does not need any knowledge of the source programming language.
• It also does not require shipping any runtime stuff.
• And it won't mess with the source code of developers.
• And it's also intuitive.
• And it's very easy to implement (grouped classes detection and expansion is simple)

Please let me know if I could convey my solution, and please tell me what can be the problems with this approach.

[wongjn]

• It also does not require shipping any runtime stuff.
• And it won't mess with the source code of developers.

Unfortunately, one of these would have to be false. Let's take PHP for example, say I have some PHP code:

echo '<div class="md:(mb-20,p-20)"></div>';

or

function add_my_classes($classes) {
  $classes[] = 'md:(mb-20,p-20)';
  return $classes;
}

With the way many PHP applications are structured, this is the source code and the production code that would be on the server. Tailwind would have to transform this and thus would alter the source code. Or conversely, if it did not, a runtime would need to be shipped to transform the md:(mb-20,p-20) on the client.

[Nefcanto]

@wongjn Although some developers go on the production server and change files directly there, at the end of the day they should come back and apply those changes in the development code.

The PHP script on the production machine, is the production code. They either should not change it or in case it's urgent, the classes are still pretty straightforward.

I completely disagree with the point you mentioned.

[adamwathan]

@Nefcanto What you are suggesting is that Tailwind should become a compiler for your actual template files.

So say you are working on a PHP project, now you need to have all of your regular source code in one folder, and Tailwind needs to transform that source code and "build" it to another folder like dist or something, where we take a file like welcome.php and generate a new copy of welcome.php somewhere else that has the class names transformed.

To me this is just totally outside the scope of Tailwind and introduces a lot of complexity. So many programming environments are designed to execute the actual source files, not execute a separate compiled version of the source files generated by a CSS framework.

I don't know how this would even be possible in a Laravel project for instance — Tailwind would basically be responsible for cloning the entire project into a new gitignored folder and you'd have to run your dev server from the generated folder instead of the source files, which just seems extremely heavy handed and weird to me.

If part of using Tailwind meant making Tailwind the tool responsible for duplicating all of your code into a new compiled folder with the classes changed, my gut is that it would just be far too much for people to stomach just to generate some CSS, and the complexity of the project itself and surface area for potential bugs would increase dramatically.

Put another way, making Tailwind force users to go from this project folder structure:

app/
bootstrap/
config/
database/
lang/
public/
resources/
routes/
storage/
tests/
├─ composer.json
├─ package.json

...to this:

├─ dist (copy of code generated by Tailwind with classes expanded)
   ├─ app/
   ├─ bootstrap/
   ├─ config/
   ├─ database/
   ├─ lang/
   ├─ public/
   ├─ resources/
   ├─ routes/
   ├─ storage/
   ├─ tests/
├─ src
   ├─ app/
   ├─ bootstrap/
   ├─ config/
   ├─ database/
   ├─ lang/
   ├─ public/
   ├─ resources/
   ├─ routes/
   ├─ storage/
   ├─ tests/
├─ composer.json
├─ package.json

...just to expand some class names feels like an extremely bad trade-off in complexity to me.

[Nefcanto]

@adamwathan that was a compelling argument. Yeah, you're right. Doing all that to accommodate class name expansion is a bad decision. But I didn't mean Tailwind to become a compiler. I meant somehow to hook into existing compilers and do some work. Some pre-compile work.

However, I still think we need to find a way to expand our classes somehow. Why do I say that?

It's because we're using Tailwind for literally every project we have. It's now about a year I guess that we have not written one line of CSS in any other form. That's how good your invention is. And I'm truly thankful for it. It helps a lot with clean code + rapid development.

Yet that md:(text-red-500,font-bod) thing is very ugly and ruins the spirit of Tailwind which would make our codes clean.

My recommendation is that we have a simple run-time that is not enabled by default and we could configure it to opt-in.

For example in my tailwind.config.js:

module.exports = {
    includeClassExpansionRuntime: true
}

Then in my layout code:

import { classExpansionRuntime } from 'tailwindcss`
// then somehow call it:
// classExpansionRuntime.expandClasses();

Then in our code, we can write:

md:(text-red-500 font-bold)

[stephenkoo]

I'm really hoping this gets implemented due to long chained states.

E.g.

supports-[not(container-type:inline-size)]:min-height-[10px]:hover:bg-red-200 supports-[not(container-type:inline-size)]:min-height-[10px]:hover:border-red-500 supports-[not(container-type:inline-size)]:min-height-[10px]:hover:text-red-500

Could simply be written as:

supports-[not(container-type:inline-size)]:min-height-[10px]:hover:(bg-red-200 border-red-500 text-red-500)

[dzcpy]

Sorry for a bit of off topic, may I ask what syntax is min-height-[10px]?

[robbyrice]

That is the arbitrary value syntax https://tailwindcss.com/docs/adding-custom-styles#using-arbitrary-values

[stephenkoo]

I've been thinking, would this be feasible & desirable syntax for longer more complex tailwind classes? (Inspired by styled-components)

import { tw } from 'tailwind'

const Component = () => {
  return (
    <div className={tw`
      bg-red-500 text-white p-4 rounded

      supports-[not(container-type:inline-size)]:
        w-1/2 mx-auto sm:w-full sm:mx-0

        min-height-[10px]:
          h-10 sm:h-20 md:h-30 lg:h-40 xl:h-50

          hover:
          focus:
            bg-blue-500 text-black p-8 rounded
    `}>
       Hi
    </div>
  )
}

If done with tailwind currently, it would look like:

const Component = () => {
  return (
    <div className="
      bg-red-500
      text-white
      p-4
      rounded

      supports-[not(container-type:inline-size)]:w-1/2
      supports-[not(container-type:inline-size)]:mx-auto
      supports-[not(container-type:inline-size)]:sm:w-full
      supports-[not(container-type:inline-size)]:sm:mx-0

      supports-[not(container-type:inline-size)]:min-height-[10px]:h-10
      supports-[not(container-type:inline-size)]:min-height-[10px]:sm:h-20
      supports-[not(container-type:inline-size)]:min-height-[10px]:md:h-30
      supports-[not(container-type:inline-size)]:min-height-[10px]:lg:h-40
      supports-[not(container-type:inline-size)]:min-height-[10px]:xl:h-50

      supports-[not(container-type:inline-size)]:min-height-[10px]:hover:bg-blue-500
      supports-[not(container-type:inline-size)]:min-height-[10px]:hover:text-black
      supports-[not(container-type:inline-size)]:min-height-[10px]:hover:p-8
      supports-[not(container-type:inline-size)]:min-height-[10px]:hover:rounded"

      supports-[not(container-type:inline-size)]:min-height-[10px]:focus:bg-blue-500
      supports-[not(container-type:inline-size)]:min-height-[10px]:focus:text-black
      supports-[not(container-type:inline-size)]:min-height-[10px]:focus:p-8
      supports-[not(container-type:inline-size)]:min-height-[10px]:focus:rounded"
    >
      Hi
    </div>
  )
}

To address Adam's findings of group variants causing more html/css bloat, the styled tagged template literal simply compiles to regular tailwind classes like above.

I've read @RobinMalfait 's comment with the example

let classes = tw`md:(font-bold,underline)`

and am aware this probably would benefit only JS projects, but I think it would greatly benefit those who do use JS.

[coycoylaniba]

+1

[andershagbard]

Semi related to: #10925

[stephenkoo]

Just curious, how have others dealt with multi-chained states and queries in Tailwind?
I find it hard to read and debug tailwind classes once dealing with non-trivial scenarios that combines various factors like:

• varying styles based on variant & intent props (aware cva may be a solution here)
• multiple queries & states (e.g. using supports, prefers-color-scheme, @container & :disabled/:hover together for multiple styles)
• fallback styles e.g. (a) applying height-[100svh] with a fallback of height-[100vh] and (b) applying the same 30+ styles to when @container sidebar (min-width: 400px) as well as fallback @media (min-width: 900px) when supports-[not(container-type:size)] ?

Aware these may be contrived examples but they're not far off from my experience using css (e.g. i want to style my buttons to handle a combination of motion preference, dark/light modes, hover/active/disabled states, variant (solid, outline) + intent (error, success, primary), width at particular container queries with a media query fallback.)

At some point, grouping variants together may not be a sufficient solution to aid readability without the clarity of an indented/nested CSS structure to easily "drill-down" to what styles apply to a given state of a component.

[Toysoldier34]

This would be a great feature, even if it is something we have to opt into with a note about how not all systems may play well with it.

Tailwind quickly becomes a pain to read and organize once there are many conditional class styles being applied. I have not found a great solution for this other than moving to something that isn't Tailwind, or trying to implement one of these custom workarounds to add the feature ourselves. I have seen regular enough requests for the feature over the years, it is a shame there isn't an official option to help reduce redundant code that can really bloat the class names in our files as it would be a great quality of life improvement.

[Nefcanto]

@stephenkoo your solution is great. The point is that the Tailwind team has gone proud (no offense, just saying what I see). They do not listen to the community anymore. It happens to a lot of teams over the years. They started something extremely amazing, a revolution. But that made them think that they know everything and the rest of the community knows nothing. That's why we're here now.

We use Tailwind for 100% of our projects. We do not have one line of CSS or LESS or SASS or CSS-in-JS or styled-components or any other tech.

Yet we have experienced extremely dirty, unmaintainable code as you mentioned. When we want to do combine things, the current solution is simply not enough.

[sarimarton]

@adamwathan What is the downside of supporting the grouping syntax on Tailwind side, and leaving the template transformation responsibility to userland? Tailwind could simply let the door open for the ecosystem to accommodate to it. This would be an additive feature, not impacting the current status quo. To make this feature work, we need involvement from both the ecosystem and Tailwind-side. Tailwind could simply (even silently, or not loudly communicated) do its part.

I understand that it might be confusing that Tailwind provides something which doesn't do anything on its own, but it would be more like an "enabler" feature. But seeing the demand and that how intuitive this would be anyway, I think it'd be worth. I also see the possible pitfall of having double parsers (one from Tw, one from ecosystem) which does the distribution. But given the relative simplicity of the syntax, at least on a conceptual level, I still think it could be worth.

[silicakes]

Thanks to @wongjn , this can now be done relatively easy:
#11701 (reply in thread)

Kudos @wongjn !

[MrOxMasTer]

It's sad that we can't be given this feature in any form. Because in reality it is not convenient to write it and debug it too.

[gustavopch]

There's this plugin: https://github.com/brandonmcconnell/tailwindcss-multi

[alanxp]

Would love to see this feature to come up, would save lots of headaches upon debuging components or even editing them. Not so much text would be nicer