41–50 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!
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!
I used to think this way, but 1) it’s easy to do a find replace of f-green and 2) turns out no one we work with changes websites this way. The closest I’ve seen is changing a font site wide with some size etc adjustments
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!
So visionary to be considered a wtf. Thanks for the submission, made my day !
Yep, Tailwind didn't invent style tokens or composable classes! After learning Foundation, Tachyons, Material UI, Chakra...I was happy to see we finally settled on Bootstrap. Oh, we didn't? Well, time to learn a new syntax. (Was it ` dark:md:hover: text-slate-400` or ` hover:md:dark: text-slate-400` again?) At least Tailwind arguably has more benefits than its predecessors.
Earlier quoted context omitted.
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
That way there is no repeated rules like in the final compiled @extend/@apply operations.
I will always argue against this. Keep your layout in one file and your styling in another. I've done more CSS than most in heavy web production and I never once had a reason to think something like this would be faster or more efficient.
I will always argue against this. Keep your layout in one file and your styling in another. I've done more CSS than most in heavy web production and I never once had a reason to think something like this would be faster or more efficient.
At my current job, I work on a legacy application which is still actively developed and released. I spend a lot of my time cleaning up inline styles, styles that are applied via javascript calls, and style blocks on individual pages. I wish the inline styles would have been utility classes, because at least then they would be easy to find and replace, instead, there are "margin-top: 3px" and "margin: 4px 0 0" and "padding-top: 2px" and dozens of variations on that that had they just done something like ".mt-small { margin-top: 3px }" there wouldn't be so many variations and inconsistent looking pages. This company would have benefited greatly from Bootstrap or Tailwinds. I hate both of those, but there is no denying how easy they are to use and abuse.
Earlier 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…
Perhaps I'm just old-fashioned but I prefer semantic classes. I completely rewrote the CSS for my website and I did not need to touch the templates. An .error is an error and a . collapsible is a collapsible. Their exact style is not dictated by the markup. I also like that it keeps the markup small and easy to read, because it's not peppered with CSS. It also avoids situations where two widgets look different becaus…
Restyling a website without changing any of the markup is a pipe dream from the CSS Zen Garden days when websites were much simpler and more static. Apart from small/personal/static websites, it just never happens in practice today.
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.
Class definitions are not CSS. They're markup. The CSS selector language does let you target them (with a leading dot, as in .foo)—just like CSS lets you target other things defined in markup with special syntax: element IDs (#bar), attributes ([foo=bar]), etc. It's not as if HTML existed without classes and without CSS, and then CSS was invented and with it came classes, too.
(This isn't to say that you're alone. A frighteningly high number of people reveal through their choice of language an apparent belief that `class` was invented by the CSS working group (or something). That when you're writing HTML, evidently 95% of it is HTML proper, but then when you get to the part where you type out 'c', 'l', 'a', 's', 's', that you're shifting into CSS and it's like, "This last piece with these "classes" was contributed by the CSS folks, and so that's why/how CSS leaked in," without ever seeming to realize that... they're not actually writing CSS. It's still just markup—using the ordinary syntax for specifying attributes and their values. The CSS only happens when you, uh, start writing CSS...)