Update: Created a crude github repo for Airfoil. It's mostly just a placeholder right now.

My previous post on TailwindCSS got a lot of views and comments.

To my horror, while I've convinced many not to go down the path of Tailwind, a few others including, (grumble, grumble) my team lead, still think Tailwind has some good ideas.

And here are some of his points:

• Its valuable to be able to define a custom style within a single class, then use that wherever. For example: example box-shadow, border radius, different colors, font styles...
• Tailwind (with the CSS-in-JS tool, twind) provides a mental model to organize utility classes without polluting the global stylesheet.
• If you're going to use a utility class approach, why not use the same one as thousands of other developers? Otherwise you need to document your stuff well.
• I think the alternative: building, managing, planning, documenting, fixing our own utility class solution is a nightmare.

And then he said some words I think he might now regret:

If you think you can do a better job I would love to see how you'd approach it.

WOO! WEEKEND PROJECT

The truth is, yes, I do think I could do better. And I don't think it would take that long.

To his points directly: I think that we can define a much smaller subset of the features of Tailwind, and do it better. I think that the cost of "building, managing, planning, documenting, and fixing" our own library that is tiny (relative to Tailwind) is going to be easier than maintaining Tailwind in our projects, (as I believe Tailwind doesn't remove code you have to maintain, it just obscures it.)

Let's be clear - in this library, (working title: "Airfoil") I wouldn't want to do everything that Tailwind does, because I'm firmly convinced 97% of what Tailwind does, Tailwind doesn't need to do, and indeed, shouldn't do.

Instead, I'm talking about extracting only those utility classes which actually provide a good shorthand for complex concepts in CSS.

So for example, I can see how someone might like the shorthand "container" for something like this:

/* breakpoints */
--breakpoint-sm: 640px;
--breakpoint-md: 768px;
--breakpoint-lg: 1024px;
--breakpoint-xl: 1280px;
--breakpoint-2xl: 1536px;
.container {
  width: 100%;
}
@media screen and (min-width: var(--breakpoint-sm) {
  .container {
    max-width: var(--breakpoint-sm);
  }
}
@media screen and (min-width: var(--breakpoint-md) {
  .container {
    max-width: var(--breakpoint-md);
  }
}
@media screen and (min-width: var(--breakpoint-lg) {
  .container {
    max-width: var(--breakpoint-lg);
  }
}
@media screen and (min-width: var(--breakpoint-xl) {
  .container {
    max-width: var(--breakpoint-xl);
  }
}
@media screen and (min-width: var(--breakpoint-2xl) {
  .container {
    max-width: var(--breakpoint-2xl);
  }
}

This, to me, is the perfect example of when a utility class makes sense to use. One word: "container" replaces 30 or so lines of code. It's reusable and does what it says on the tin. The only thing I'd do differently is name it 'with-container' rather than 'container', as I think the prefix 'with-' makes a lot of sense for a utility class to distinguish it from a semantic class.

And if Tailwind were full of code like this, I wouldn't have a problem with it.

But "container" is one of the eight or so exceptions which prove the 200+ rules that Tailwind is just full of stuff that can be replaced by one or two lines of CSS.

.flex {
  display: flex;
}
.py-6 {
  padding-left: 1.5rem;
  padding-right: 1.5rem;
}

So I went through Tailwind's documentation, and picked out the nine classes that I'd actually keep out of the 200+ that Tailwind offers.

And they are:

• container
• ring
• box-shadow
• filter (but possibly as a function/mixin)
• backdrop-filter (which will be difficult as neither Edge nor Firefox support backdrop-filter natively)
• drop-shadow
• animate-spin
• animate-ping
• animate-pulse
• screen-reader-only

And at this point, if you're saying to the screen: "Well, what about X?" -- that's why I'm writing the post.

I'm soliciting comments on what you think needs to be added to such a library. Maybe it's in Tailwind and I missed it. Maybe it's not in Tailwind, but you wish something like it was.

I also would like to know how you think it should be developed. I think right now, the goal is to start life as a .CSS file on Github Gist, to get the proper effects right.

Then, provide two different versions - one as styles and mixins as a partial (_airfoil.scss?) for an SCSS file, another which takes a function and just returns a string, for integration into libraries such as styled-components and emotion/css.

But again - before I do that, I need to scope out the project. So - please retweet this among your dev friends, both "pro-tailwind" and "anti-tailwind" and talk about what you'd like to see - or not like to see - in the comments below.