Hacker News Reader

Comment by hipadev23 | Hacker News Reader

My gripe with Tailwind is the redundancy of class definitions across elements that clearly would benefit from "normal" CSS. If I have a <table> with a whole host of <td> elements, those repeated class definitions become quite tedious.

View on HN

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.

Part of the problem with the tailwind debate is that the appeal of tailwind is not just having your styles in your html, it's also having predefined style units, e.g. size intervals for things like margins.

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.

I still think it would be nice if CSS natively allowed you to combine classes the way these @extend and @apply operators do

In practice, I never have found much benefit to that. If I need a base class, I will create a base class. .validation-message for instance, then if the validation is a success/error/warning/info, I will write those classes, then my validation message element will have 2 classes on it "validation-message warning"

That way there is no repeated rules like in the final compiled @extend/@apply operations.

You can't reinvent something that was never invented to begin with. "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...)

And then you are just writing css with a more obtuse syntax.

Cool. So @apply is basically a way to compose classes from other classes?

This was already an option with Sass's @extend (later ported to a PostCSS plugin)

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.

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.

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.

> This is all very well solved in semantic web

If it was solved with "semantic web" (whatever that means), we wouldn't have people attempting to solve this again, and again, and again.

> If it was solved, people wouldn't try to solve it again.

Remember when serverless got invented even though CGI already existed?

I'd say it was rebranded :)

That's patently false. The webdev community does nothing but reinvent/rediscover the wheel e.g. SSR.

What does SSR have to do with semantic web?

All "semantic web" can provide is a flat CSS namespace and a bunch of nested divs.

Even if you do everything right there's nothing semantic about it: https://inclusive-components.design/cards/

Reply on news.ycombinator.com