Which CSS frameworks are you using and why?

Author

Definitely if you're looking to make the switch. The syntax isn't 1-to-1, but it's very close.

Author

No, most people see the similarity when it's done like that. Most people don't think it's a problem though.

You can use it more like regular separate styles - i.e. you make a stylesheet with semantic selectors and import the utility classes you want:

main {
  @include relative;
  @include flex-col-reverse;
// ...

nav {
...
}

I can't remember the syntax, so treat that as pseudo-css, but you get the idea. From that approach it's not terrible, and it's no longer the equivalent of inline styles, but it still has a bunch of problems. For example, why is there a redundant flex class, when we're also using flex-col-reverse? The latter should include flex as part of its definition anyway.

Unfortunately, that's not hugely different from, you know, writing CSS/Sass. Worse, it's not how anyone does it. As the example from their own website shows, and as innumerable posts here show, what people do in real life is use Tailwind as if it were opinionated inline styles.

I strongly disagree, and think Tailwind - in either use case - is a problem more than a solution, and it's giving us a worse web.

In the CSS-Tricks article about "Atomic CSS" it gives examples like this:

<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>

coupled with this:

.Bgc\(#0280ae\) { background-color: #0280ae; }

which I cannot fathom anyone defending.

In the original Challenging CSS Best Practices article referenced there, the author says:

When it comes to CSS, I believe that the sacred principle of “separation of concerns” (SoC) has lead us to accept bloat, obsolescence, redundancy, poor caching and more. Now, I’m convinced that the only way to improve how we author style sheets is by moving away from this principle.

I'm inclined to think that if separating style from content leads to bloat, well, it's not because you're separating those concerns, it's because you're doing the styling wrong. There is, by definition no bloat on the content side, and the style side is up to you to organise. Keeping simple templates and using semantic elements rather than making everything yet another div goes a long way to making it simple.

If the problem is that - as @natescode says, and I know he and I disagree on this :) - regular approaches don't scale that well, then you have to consider the flip side. People add content through WYSIWYG editors, and that pre-marked-up content goes into your data store. In order to change the styling, you either need to do heavy database work, or you need to mark up semantic elements correctly in the first place. For most of us, though, the sort of scale where things get out of hand with CSS is either found in legacy spaghetti-coded sites which have a lot of other problems, or it's a scale we'll rarely need to reach.

Thread

Thread

Thread

Thread