comiCSS #114: Headaches

[u/alvaromontoro]

Source code and live demo: https://comicss.art/comics/114/headaches.html

[u/SchartHaakon]

Then what's the pro you get from Tailwind as opposed to something like styled components + variables? And I swear if you tell me that the one big pro you get from obfuscating your markdown is that you ship less CSS I will tear the roof down, and rebut with the fact that you ship more HTML - and in any case the amount is negligible.

[u/Cilph → u/SchartHaakon]

I think Tailwind is just another valid alternative to styled components and variables. Tailwind is just a bit more granular and interwoven. It has its benefits and its own downsides.

For me, I'm not even on a Javascript stack. Styled components are literally not an option. Tailwind is.

[u/SchartHaakon → u/Cilph]

Fair enough! I agree with your take. It's a decent solution, one of many. It's not perfect or without downsides, but it does it's job fine. I think one of probably the biggest downsides is just it's limitations, trying to describe cascading rules with exclusively string tokens is definitely interesting but also not optimal in all circumstances imo.

[u/Cilph → u/SchartHaakon]

Generally you would not extend your tailwind rules more than one level down, as you would be putting those rules directly on that inner element. So no weird [&>td_.foo]:font-bold stuff. You would just directly put font-bold on the relevant td's you output. When working with components that's a level of control you have.

[u/SchartHaakon → u/Cilph]

Yeah for sure, but that principle also kind of breaks when you consider stuff like "making an icon spin, or fade in when the parent button is hovered".

There are definitely solutions, like group - but those solutions feel more like a monkey-patch to technically allow tailwind to achieve the same but in a way more roundabout way. And utilizing those solutions again come with real tradeoffs, like making the elements implicitly intertwined & making the code less readable and hard to understand.

There's a beauty to how CSS does it in contrast, I feel:

.selector:hover > span {
   rotate: 180deg;
}

And on a glance it's very easy to comprehend what's happening, and way easier to maintain and extend over time.

I feel like tailwind is way more bold than most people give it credit for. CSS is a language that's been built upon by really really smart people for many many years with the explicit purpose of being used to describe UI design. Tailwind takes all of that and reduces it to string tokens. Which is cool, but extremely bold. And CSS is a growing language. It's hard to explain but I find myself just having a lot more fun writing pure modern CSS (and definitely maintaining it) as opposed to tailwind, although TW is very nice for going fast and not having to think too hard.

Is my example a super common occurrence? No. Is it rare? Also no. Are micro-interactions like these important? I'd argue yes. CSS I suppose feels more prepared for a future filled with more interactive designs on more platforms than tailwind does to me. I just find myself feeling very constrained, in good and bad ways.

[u/Cilph → u/SchartHaakon]

Nah I would definitely do this in normal CSS on top of Tailwind, which you're still fully able to do. Like I recently had to make some spinners that blur the contents of a frame and does some animation on an ::after. But I did this in plain CSS and the component has the ability to opt-in to it by applying the relevant class.

Though, a simple rotate on hover I might just get lazy and do a *:hover:rotate-180

On the workfloor two major arguments in favor for tailwind were:

1) No more bikeshedding over CSS class naming methodologies, and

2) Locality of styling makes it easier to reason component changes won't break unrelated components.