Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

101–110 of 435 posts

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

#101
post #42

Earlier quoted context omitted.

It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself). It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might b…

Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tai…

> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component.

This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.

> And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component.

Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!

> There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.

...and now you have three problems.

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

#103
post #70

Earlier quoted context omitted.

Yeah, that's a straw-man. I've worked on large-scale projects with many team members, and it's perfectly possible to use CSS as it was designed. But sure, like most tools, it starts with understanding how it works.

Sure, but "total ignorance of how CSS is made to work" is also a straw man.

[deleted]

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

#104
post #2

Relying on React or Typscript in LLM era seems very stupid, just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop. Far more offline compatible development almost negligible supply chain issues as well. At least ones you can control.

> just have the LLM setup whatever dom manipulation you want and have it write decent JS without slop.

Hmm, yes, simply have the LLM write good with no mistakes.

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

#105
CSS Modules are a simpler solution to cascading problems. They create unique class names, so your classes don't clash [1]. And they don't have the two main downsides of TW, which are readability [2] and tooling. Tooling for debugging and experimenting interactively with Chrome and FireFox DevTools.

[1] https://x.com/efortis/status/1888304658080256099

[2] https://github.com/ericfortis/tailwind-eye

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

#106
post #18

Earlier quoted context omitted.

This isn't about "purity/correctness" it's about the real experience of a blind person. Accessibility means caring about the HTML. Your comment only mentions developers as the audience of HTML authoring, as opposed to users, which is a common attitude and the core problem with Tailwind.

I use Tailwind and have all kinds of "screen reader" directives in my templates. Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them. It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".

I mentioned blind but there’s lots of others. Folks sitting a desk whose eyesight are getting worse and are scared to say so for fear of losing their job, for example. This happens.

Side note: if you aren’t deliberately choosing semantic elements and instead dropping aria attributes onto a bunch of divs this is an anti-pattern.

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

#107
post #54

> 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…

> can tailwind be used poorly? absolutely. but that's true of any tool

Can tailwind be a useful CSS framework? Absolutely, but that can be said of any of them.

Which is precisely why it makes sense to point out it's unique flaws, so that people can make an informed decision as to what works best for them.

If you have some unique feature to tailwind that you think makes it better than the rest, you should share that.

Everything you have listed is also accomplished by all the other CSS frameworks, so it almost sounds like tailwind is simply the main one you have experience with.

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

#108
post #68

Earlier quoted context omitted.

You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on. Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally mak…

Every moment you spend doing accessibility is a moment you spend not doing other things. You could argue it has a high RoI to do accessibility, fine, but that doesn't make it lazy _not_ to do it. Maybe I have even higher RoI/EV stuff to be doing.

> Maybe I have even higher RoI/EV stuff to be doing.

I mean, to readers of these comments, I think it's right there for you: 0x3f will take "higher ROI" over "accommodate and support disabled people".

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

#109

> 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 find your comment quite refreshing.

25 years ago, I was appalled how Microsoft Frontpage could transform a very simple word document (with little formatting) into an utterly indecipherable mess of HTML that rendered correctly.

With very simple transformations, I could paste the text of the document into notepad and add just a few heading tags for the same rendered result but a much more understandable source.

CSS had a lot of promise for simplifying the HTML content, but the world tried its hardest to prevent that.

Now we have multi-megabyte monsters for simple webpages (before even counting graphics).

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

#110
post #95
post #36

Earlier quoted context omitted.

You call it lazy. I call it "focus" or avoiding pre-mature optimization. I find the "legal liability" claim hilarious... I do better than 95% of the web: as I said I HAVE some screen reader directives (just did not test it), and labels to make the app more accessible.

> You call it lazy. I call it "focus" Is this to be read that disabled people and their needs, or more directly from the replied-to comment, "doing the right thing", are not a focus of yours, flossly?

A former coworker of mine opened a meeting saying "we are so good, we care about accessibility". I had been complaining for months and finally a customer had said "we won't buy your product unless it complies to the law".
Post reply on HN