Coming to Terms with Tailwind

> I believe CSS' primary weakness is the general inability to define cross-cutting abstractions. I think of the style of an object as a composition of concerns: spacing, position, size, typography, color, decoration, etc.

I see this come up and it's so strange to me; the only thing I can think of is that what people are complaining about is too many ways to define cross-cutting abstractions (variables and mixins / other apply boosters and even css classes themselves) so the imposition of a framework-specific way to do it feels like it relieves a burden.

Similarly, I'd guess that you'd see a lot of overlap between people who'd chosen their own conventions for addressing this in combination with other design systems and people who don't like Tailwind much.

Whoa, no mention of WindiCSS yet — https://windicss.org/

> wouldnt

It's simpler than this honestly — the Tailwind CSS Twitter account is managed entirely by me (I made Tailwind), and I'm the only one who tweets from it and checks the notifications to see if there are people doing interesting work I can help elevate or having problems I can help with.

Seeing a bunch of incessant vitriol in the mentions all the time about something I've worked really hard on for many years is very distracting and upsetting to put it mildly, and on days when my emotional reserves are already low from the stresses of figuring out how the hell to make money working on the project or having a young family it's really not a healthy thing to have to deal with.

Criticism being delivered in good faith is welcome and productive, but constant holier-than-thou "wow whoever created this is extremely stupid compared to me and clearly has no idea what they are doing" is not that.

I've only ever blocked two people for this sort of abusive crap since 2017, in case that provides some perspective.

Tailwind CSS is a "company" now in the sense that Steve and I built a commercial product to make the OSS stuff sustainable, and it turned out to be successful enough that we could hire handful of other people to help out, but I certainly don't think of us as some sort of faceless corporate entity. We don't plan to grow the team and I don't plan to become a full-time manager — I just want to keep working on interesting OSS projects and we decided to use the revenue from our commercial stuff to make that possible by hiring people to help with customer support, working full-time on existing OSS things from the ecosystem (we hired the person who built the OSS Tailwind IntelliSense extension for example), and to keep up with the barrage of GitHub issues we see as a popular project.

Tailwind CSS itself is very much a personal project of mine and a labor of love, and for better or for worse it's not as easy to detach yourself from projects you pour that much into as people (who have no perspective on the emotional challenges of being the face of a popular and polarizing project) make it sound.

Webpack is also a single file.

> Is that bad? Not using Tailwind forces you to have a separate stylesheet that hides tag to property relationships, among other hidden abstractions. The class names barely need to be learned. With an IDE, you get class name completion, and there are only a few properties that have unexpected names.

Well, the purpose is actually to have separate stylesheets, so that you can name them in a relevant manner, I don't know, like menus.[s]css, panels.[s]css, just like so you know where things are, and so that you can use a class to define repeating elements across a codebase. There's no abstractions in CSS that aren't present or amplified in tailwind - there's pre-processing utilities that are useful in tailwind but they're present in any pre-processor without the remaining stuff. And in fact the logical way of using CSS is by defining classes and then defining modifications to those classes, when needed, when they're part of a hierarchy of classes that requires it. They're one grep away of being discovered in all css files.

> What do you mean "the point of CSS"? Read the spec. It says nothing about the number of properties a class should contain.

Uhh. Yeah, I might one day, but I don't get what you're saying.

> If you mean classnames should be higher level abstractions than CSS properties,

A classname is a selector token, that you can place in CSS hierarchies and define a set of rules, that affect the elements using that classname. It's obviously a higher abstraction than a style rule.

I wasn't talking about semantic html5, I'm talking about semantic markup for readers of the code. If I see "t-4 h-3 w-2 mongo-xyz bg-pearl-800 flex flex-col m-4" I can understand it after reading all of those properties in tailwind, perhaps and how they all interact. But I'll need to understand that it uses relative sizes (like, why...) that m-px is one 1px, m-4 is 1rem, but what I want is fixed sizes 99% of the time. That someone might have disabled some of the sizes generation. Then I don't know, if someone asks me to change the styling now I have to go through all the codebase, searching for elements that are styled like that, because I have not way of identifying it and I have to change all their classes to the new style. Obviously, it's much harder to have it placed in a single file. Inline classes are better somehow than inline styles (although you can't know exactly what it's affecting), and there's a place for inline styles, but 99% of the time it's bad.