31–40 of 76 posts
It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability. Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!
Earlier quoted context omitted.
Tailwind is one of those polarizing topics where people either love it or hate it. I've used it at a few companies and I didn't care much for it, but I had coworkers who swore by it.
We've been using it for a little over a year. So far my biggest finding is that Tailwind works best when you have a UX team that is forced to play by the same rules. In that context, with a heavily chopped down tailwind.config, it comes alive as a utility. It can even act to proof mistakes in the UX work. A div with a 1rem padding, with a BG of neutral lightest and a text color of "primary" is a spec defined by class…
I agree but found that Bootstrap (>v4) to be better at this. Instead of every possible color and tweakie, Bootstrap has pretty decent utility classes that are semantic, and in addition to all the basic components like button, etc:
It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability. Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!
Nope. Green should give you green.
Back in the day we made fun of this nonsense, now we freakin glorify it with libraries like Tailwind & friends...
But when you want to redesign a whole site after the fact, or if you want to keep your component library logic & templates, and port it to a new system, Tailwind might be more trouble than it's worth.
It's just that... Atomic CSS has its benefits, BEM has its benefits, etc etc etc.
Instead of .f-green in your HTML you can do --f-green in your CSS.
would become
header { color: var(--f-green); }
or if you really hate CSS and must stay in HTML
Though the literal naming is a touch too specific anyway. Something like this is wonderful:
--f1-color: green;
header { color: var(--f1-color); }
then you don't have to do confusing things like
header .f-green { color: red; }
because you can do
header { --f1-color: red; }
So we can be less specific AND more modular... because you can have that f1 (font1) color be red in your header, and still do:
footer { --f1-color: green; }
We can make really flexible and extensible systems with modern vanilla CSS. No frameworks or preprocessors needed.
Earlier quoted context omitted.
Use PostCSS: .myFancyTable td { @apply p-4; } The advantage of Tailwind, IMO, is that styles for one-off components (like a breadcrumb bar) can just be written inline instead of in a separate file. But reused components like table cells should be using CSS selectors.
Congratulations, you have reinvented the purpose of CSS classes. This is why I don't use Tailwind, at a big enough scale, it becomes lots of duplication, and if you use @apply, it's just...CSS classes as originally designed.
CSS variable libraries like open-props also do this, only without the controversial use of utility classes. Add editor snippets to that and you have nearly the same ease of use as tailwind.
Earlier quoted context omitted.
The big thing about tailwind in the context of JS rendering is that this ends up being a code smell. If you find yourself repeating a set of classes...you probably should componentize that and DRY.
It's funny how the solution (use CSS as it was intended) is now being transformed into JS-powered component solutions. But yeah take say a dashboard layout with a lot of cards of different sizes. They're going to have the same underlying design, padding, rounded edges, background colors, etc -- and usually only vary on maybe size and breakpoints. This is all very well solved in semantic web, but it feels to me like t…
If it was solved with "semantic web" (whatever that means), we wouldn't have people attempting to solve this again, and again, and again.
Earlier quoted context omitted.
My gripe with Tailwind is the redundancy of class definitions across elements that clearly would benefit from "normal" CSS. If I have a with a whole host of elements, those repeated class definitions become quite tedious.
Use PostCSS: .myFancyTable td { @apply p-4; } The advantage of Tailwind, IMO, is that styles for one-off components (like a breadcrumb bar) can just be written inline instead of in a separate file. But reused components like table cells should be using CSS selectors.