Comment by 734129837261 | Hacker News Reader

Comment by 734129837261 | Hacker News Reader

Parent Full thread

The problems he's tackling weren't problems, and his solutions are a bombardment of utility class names in your HTML, rendering it extremely and unnecessarily verbose. It makes the HTML less intuitive to read, too. A `<div class="user_profile">` is clearly a container for a user profile, a `<div class="here comes a shitload of tailwind class names because inline styles are now apparently cool again">` tells you absolutely nothing about what the hell is going on.

I fucking LOVE CSS and Tailwind is an insult to the craft.

Those who love Tailwind tend to not understand CSS beyond the basics, is what I've learned. Those who hate Tailwind know CSS inside and out.

To each their own, but this example from their own homepage makes me want to vomit:

          <button class="flex-none flex items-center justify-center w-9 h-9 rounded-md text-gray-300 border border-gray-200" type="button" aria-label="Like">

Like what the actual flying fuck. This is inline CSS, period. And that's wrong, always. Tailwind makes me mad and angry because I love front-end development, I love CSS, and everything about this feels like a mentally challenged person spitting me in my face. Nothing I can do about it, they are challenged after all, but damnit it's annoying.

> A `<div class="user_profile">` is clearly a container for a user profile, a `<div class="here comes a shitload of tailwind class names because inline styles are now apparently cool again">` tells you absolutely nothing about what the hell is going on.

You know what's going on if you're in a component called user-profile.component.html

How often are you writing something like a user profile component in the context of something much larger? Also, what styles would the class "user_profile" even have? You say the second one "tells you nothing about what's going on," but I'd say it's the opposite. If you actually put real tailwind classes in the second one, I'd know exactly how that div is styled whereas the first one requires cross-referencing another file.

"user_profile" probably has CSS implementation that have almost nothing to do with a user profile. It's probably a container that has maybe a margin, a max-width? The important styling details all come from the inner HTML and stylings on those things. So your "user_profile" class is mostly just another generic wrapper that you had to come up with a name for.

As an example, I'd say this isn't semantic HTML:

    <div>heading</div><div>bob is a person</div>

This is better:

    <h1>heading</h1><p>bob is a person</div>

This is less clean but has the same level of semantic detail in the HTML:

    <div class="container"><h1 class="home-heading text-center">heading</h1><div class="m-10"><p class="home-body color-blue"><div class="first-name">bob</div> is a person</div></div>

Am I missing something?

I think people conflate semantic class names (read by programmers and maybe ad-hoc web scrapers) with semantic HTML (read by screen readers, SEO bots). Semantic HTML is HTML that uses the appropriate semantic HTML tags, but including wrapper divs and CSS class names on top of this doesn't make it less semantic to a machine.

For styling, when a utility class is all you need to style a particular tag and it's obvious from context what that tag is being used for, I don't see to reason to spend time trying to come up with a semantic name e.g. `home-hero-wrapper-inner`.

To me, this is people dogmatically sticking to a "best practice" without thinking about the pros/cons and reason behind it. This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML.

> This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML.

Which I also think is weird, because the hierarchy of HTML is inherently styling/presentation. If HTML was truly decoupled from styling, you'd just throw all the tags that you want into an HTML file and then arrange them around with CSS.

That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor.

> That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor.

Yep, trying to keep data and presentation separated like this comes with a lot of pain. Why bother? I don't see the practical benefits in real-life projects as long as you're still using semantic HTML tags.

There's this other pipedream that the HTML is generated/written by people that aren't concerned with the presentation and then the CSS can be swapped in to style it however you want. You can and should do this in a sense that you keep your data/articles/posts in Markdown, SQL databases, behind APIs etc. - I think trying to split this further at the HTML/CSS level isn't gaining anything.

but what does "user_profile" tell you, as a developer, when you need to style the element?

Reply on news.ycombinator.com