This is what I did before stumbling on BEM - https://en.bem.info/methodology/css/
Now that you're familiar with BEM you can use the perfect css approach `.page__inner__title-f-green {color:#0f0;}` imagine the portability!
Styling with Classy CSS (2006)
21–30 of 76 posts
Re: Styling with Classy CSS (2006)
#22Earlier 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.
And then you are just writing css with a more obtuse syntax.
Re: Styling with Classy CSS (2006)
#23Earlier quoted context omitted.
Isnt this only a problem when the table contents are hardcoded ?
It was just an example, but it's more broadly the redundancy of a list of repeated classes applied to elements that are identical or mostly identical. These are things that CSS literally solved with the web2.0/semantic-web movement 20 years ago. I get the convenience of Tailwind but a lot of it feels like a massive step backwards.
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.
Re: Styling with Classy CSS (2006)
#24Earlier quoted context omitted.
Why do you feel it's nonsense? I'm genuinely curios. Personally I'm using Tailwind for 90% of the styling. If I keep repeating a certain combination of classes often, I'll group it with a custom class. (Edit: See colejohnson66's comment for an example) Two advantages of tailwind that I didn't see before I started using it: - It's often easier to find what I want in the tailwind documentation, and it comes with nice e…
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 names and a mock. I honestly think that in uncontrolled environments without a singular design system and without configuration, tailwind can become a mess. I really do not care for the out of the OOB config, it is way too free on color schemes. You need a few people to play the rulemakers and constraint for it to be helpful.
Re: Styling with Classy CSS (2006)
#25Back in the day we made fun of this nonsense, now we freakin glorify it with libraries like Tailwind & friends...
Why do you feel it's nonsense? I'm genuinely curios. Personally I'm using Tailwind for 90% of the styling. If I keep repeating a certain combination of classes often, I'll group it with a custom class. (Edit: See colejohnson66's comment for an example) Two advantages of tailwind that I didn't see before I started using it: - It's often easier to find what I want in the tailwind documentation, and it comes with nice e…
At a certain scale, Tailwind becomes a write-only DSL. It's almost inscrutable if you want to change something on some heavily classed HTML tag.
Re: Styling with Classy CSS (2006)
#26Earlier quoted context omitted.
It was just an example, but it's more broadly the redundancy of a list of repeated classes applied to elements that are identical or mostly identical. These are things that CSS literally solved with the web2.0/semantic-web movement 20 years ago. I get the convenience of Tailwind but a lot of it feels like a massive step backwards.
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 the JS + Tailwind apporach is creating new problems and thus new solutions to accompany.
Re: Styling with Classy CSS (2006)
#27Earlier 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.
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.
Re: Styling with Classy CSS (2006)
#28It'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!
This was the only bit in tailwind we modified a lot in our Config. You really need to remove the default colors and define them as [Primary, Secondary, Neutral, Warning, Error, Success] and then add variants of each. Then it really works. I honestly think this should be a default config change/setup option in TW. Nobody with a Design System/Brand guidelines should be including the default colors in their app.
Re: Styling with Classy CSS (2006)
#29Earlier 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.
I still think it would be nice if CSS natively allowed you to combine classes the way these @extend and @apply operators do
Re: Styling with Classy CSS (2006)
#30Earlier 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…
I think the detail is that this JS answer is really only for people working at a seriously large scale. At that size, there is absolutely zero room for non-componentized logic as cross-managing a billion pages with duplicate HTML elements is pretty unacceptable. That said, Tailwind also allows you to define your own classes that apply multiple TW classes.