Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

Post reply on HN
Print view View original

351–360 of 435 posts

Re: Moving away from Tailwind, and learning to structure my CSS

#351

Post by 9dev »

satvikpendem wrote: post #321
9dev wrote: post #120

Earlier quoted context omitted.

> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hu…

CSS modules solve all of these problems.

They don't, really. The only thing they solve is side effects, but you'll still want shared conventions across your modules.

Re: Moving away from Tailwind, and learning to structure my CSS

#352

Post by isleyaardvark »

mcv wrote: post #235
TonyAlicea10 wrote: post #3

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

This is the misconception that has caused so many problems over the years, problems that the Tailwind approach solves.

There was never any separation of concerns within the HTML code, the class="" property is in the HTML and that is the styling info. Devs took the idea of separation of concerns of content, presentation, and behavior as separation of technologies: HTML, CSS, and JS, which is not the same. So they tended to think, "oh no, with classes I've got presentation code in my content (HTML) and I need to put it all in my CSS." But HTML is not content, it contains content. And all the separation of concerns is done with how the HTML is written.

For example take this code Bleh!

That has separation of concerns. The content is Bleh!, the content semantics are h2, the styling is all in the class, and the data-index is used only as a hook for javascript. Violating separation of concerns would involve using those properties for multiple concerns. Particularly the h2 class="h2" part. It looks a bit silly at first glance, particularly if you have a bunch of and 's in the codebase. But that has proper separation of concerns, and I have many times run into cases where I want an or , and in those cases, because I have proper separation of concerns, all I have to do is change the actual content layer to whatever is appropriate without worrying about the presentation layer changing because someone put an h2 { font-size: 1.6rem; } in the css.

The only difference between the old-school approach and the Tailwind approach is the API between the HTML file and the CSS. The old-school approach tends toward terrible abstractions because devs are trying to code the presentation for an element while feeling they need to describe the presentation in as few terms as possible, because they think that amount of characters is separation of content. Tailwind takes the approach that the class property is the presentation layer and you can use your words to describe it clearly.

I'd add that what I've seen with the older approach almost always leads to much more co-mingling of concerns (maybe because those devs get so focused on "all style should be in the CSS"). That's when I see things like ul > li { padding: 1rem; }, which is fine until you decide to change it to an ol. Or even .foo > .bar { ... }, which is dependent on the structure of the content.

Yes, Tailwind is ugly as sin but it's effective.

Re: Moving away from Tailwind, and learning to structure my CSS

#353

Post by isleyaardvark »

isleyaardvark wrote: post #352
mcv wrote: post #235

Earlier quoted context omitted.

I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

This is the misconception that has caused so many problems over the years, problems that the Tailwind approach solves. There was never any separation of concerns within the HTML code, the class="" property is in the HTML and that is the styling info. Devs took the idea of separation of concerns of content, presentation, and behavior as separation of technologies: HTML, CSS, and JS, which is not the same. So they tend…

I think I can make what I wrote above a little clearer by putting it this way. When the class property gets really long, that's not a violation of separation of concerns, because you are not really co-mingling content with presentation. HTML is not content but contains content.

Re: Moving away from Tailwind, and learning to structure my CSS

#354

Post by Timon3 »

timr wrote: post #161
9dev wrote: post #120

Earlier quoted context omitted.

> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hu…

> That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? Of course. It's obviously better to…

It undoubtedly is! I'd much rather learn 10,000 different names that follow a clear naming scheme and stay consistent between different projects and teams, than 1,000 different names that aren't guaranteed to have clear names or any consistency (even inside a single team).

But I'd also like to push back on the "10,000 different names" - the overwhelming majority of those names are merely variations of the value they assign, so using any class teaches you dozens to hundreds of those 10,000 names. So realistically, the comparison is closer to "1,000 project-specific and potentially inconsistent names" vs. "1,000 consistent names valid in any project using TW".

Re: Moving away from Tailwind, and learning to structure my CSS

#355

Post by isleyaardvark »

thiht wrote: post #175
zamalek wrote: post #56

What I don't get about tailwind is: why not just use the style attribute at the point?

With Tailwind: With style: Now more interestingly, Tailwind with hover and focus styles: That’s not possible with the style attribute. Even more interesting with Tailwind, a div with dark mode and responsive styles: That’s not possible either with the style attribute. Now your first instinct might be to "that’s unreadable", but keep in mind HOW you actually read and write this code. You’re not actually reading it to…

> Tailwind code is mostly write-only and maintained by viewing what the component looks like.

I’d add that almost all code is like that, if you mean you only write it once and only look at it again if you need to make a change. And with Tailwind you generally only need to look at the one component, instead of having to go to a separate CSS file to look, and then look through the codebase to see if that code is used anywhere else.

Re: Moving away from Tailwind, and learning to structure my CSS

#356

Post by TonyAlicea10 »

troupo wrote: post #205
TonyAlicea10 wrote: post #152

Earlier quoted context omitted.

The HTML spec says divs are the element of last resort. This issue isn’t that they’re bad. The issue is they are reached for far too quickly. Also if you think massive numbers of nested divs don’t have a performance impact in the DOM when reusable components are nested (because “styling”), you’re wrong.

> The HTML spec says divs are the element of last resort. This issue isn’t that they’re bad. The issue is they are reached for far too quickly. The problem is that HTML gives us very few tools to do anything useful. And you can only push certain elements so far. Div and span are generic elements with no semantics attached. You want a layout? Div. You want a change to a part of text? Span. The only reason they are cal…

> You want a change to a part of text? Span.

You haven’t read the HTML spec. There are an incredible amount of elements, including for changing just a piece of text (b, i, strong, em, and many more). Plus elements for visual aspects like images.

You need divs and spans for extra structure that isn’t there for anything but visual purpose. For things you wouldn’t describe to someone who couldn’t see the page. That’s a lot less than you think.

HTML authoring and choosing the right elements can be fun. But you have to stop thinking visually and start thinking semantically.

Re: Moving away from Tailwind, and learning to structure my CSS

#357

Post by [deleted] »

danaw wrote: post #54
TonyAlicea10 wrote: post #3

> I got curious about what writing more semantic HTML would feel like. I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers. The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS. HTML is marking up the meaning of the document. You should start there. Then style with CSS.…

you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. but that's true of any tool i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled…

[deleted]

Re: Moving away from Tailwind, and learning to structure my CSS

#358

Post by [deleted] »

danaw wrote: post #268
TonyAlicea10 wrote: post #96

Earlier quoted context omitted.

If a tool’s design makes it easy to cut myself, the response is not “people have been cutting themselves for years”. There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one. It’s ergonomics encourage adding div elements to support styles. It’s the core design loop. You’re conflating “forces to” and “ergonomically encou…

i just don't agree tailwind makes it any more easy to make div soup than any other approach. if you don't care or know how to build proper markup no style approach is going to save (or hinder) you

[deleted]

Re: Moving away from Tailwind, and learning to structure my CSS

#359

Post by troupo »

TonyAlicea10 wrote: post #356
troupo wrote: post #205

Earlier quoted context omitted.

> The HTML spec says divs are the element of last resort. This issue isn’t that they’re bad. The issue is they are reached for far too quickly. The problem is that HTML gives us very few tools to do anything useful. And you can only push certain elements so far. Div and span are generic elements with no semantics attached. You want a layout? Div. You want a change to a part of text? Span. The only reason they are cal…

> You want a change to a part of text? Span. You haven’t read the HTML spec. There are an incredible amount of elements, including for changing just a piece of text (b, i, strong, em, and many more). Plus elements for visual aspects like images. You need divs and spans for extra structure that isn’t there for anything but visual purpose. For things you wouldn’t describe to someone who couldn’t see the page . That’s a…

> There are an incredible amount of elements

That is, a dearth of them. Most of them are still there defining basically just text content.

> Including for changing just a piece of text (b, i, strong, em, and many more)

Not as many as you'd think. If I need to layout text in a certain way and mark some of it in a certain way, there's nothing better than .

> But you have to stop thinking visually and start thinking semantically.

This sentence carries less meaning than you think it does.

E.g. there's the tag. It was literally originally proposed for text content only: https://www.w3.org/WAI/GL/wiki/Using_HTML5_article_element The spec twists this to become more generic and encompassing all other content, and still does not escape framing it as mostly text-ish elements: https://html.spec.whatwg.org/multipage/sections.html#the-art...

And here's MDN intro saying "oh, yes, if you want cards for your product catalog, or an interactive widget, use " https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Yup. "article" is "semantic" to represent cards in a product catalog.

You basically have to construct a parallel hierarchy of elements in your head with specific behaviours that doesn't match what element names mean, or used to mean.

There's nothing fun in figuring out 30 years of history of a largely outdated tech being twisted to conform to the new world of complex layouts and interactions.

Re: Moving away from Tailwind, and learning to structure my CSS

#360

Post by [deleted] »

danaw wrote: post #274
pwdisswordfishq wrote: post #228

Earlier quoted context omitted.

> nothing about tailwind forces you to build inaccessible or "div soup" apps https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... So what if it does not "force" you?

i've worked on about 8 different production teams/products with tailwind and none were div soup. does that prove your claim wrong? at what point would you accept maybe some people know how to use html AND tailwind together?

[deleted]
Post reply on HN