Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

291–300 of 435 posts

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

#291

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

That has nothing today do with TailwindCSS, we have been having the exact same thing since 1999.

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

#292

We also moved away from Tailwind — Pico CSS. It feels like a breath of fresh, modern CSS air. We actually loved it so much that we’ve taken over maintenance of a fork, and just released our Pico successor candidate: https://blades.ninja/

It is really fun that the navbar has unaligned elements. (Docs is lower)

we were focusing on Mobile and Desktop versions, are you somewhere in between?

to be tracked here: https://github.com/anyblades/blades.ninja/issues/7

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

#294
Tailwind isn't just a framework; it's a design system.

The creators of Tailwind wrote the brilliant book "Refactoring UI" [0], which presents a systematic design system, introducing ideas such a type-scales, color-scales, spacing, and tactics to minimizes the cognitive burden on the designer by forcing design choices. The ideas presented in this book basically are tailwind classes!

When you build with Tailwind, everyone is speaking the same design language, and you end up with harmonious designs, even when components came from different projects or designers.

I disagree with the author's approach. It's basically just copying the utility classes from Tailwind and implementing them in an unergonomic way. Perhaps the best idea is component level CSS which is something that's been enabled by better tooling. I would implore anyone who doesn't really get Tailwind, to read the origin story [1].

[0] https://refactoringui.com/ [1] https://adamwathan.me/css-utility-classes-and-separation-of-...

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

#295

Nice article! I'm a fan of removing any dependencies on external libraries and writing my own solution from scratch, but there's a good reason why I decided not to do so with Tailwind: They offer an optimization for production that ensures that you never ship more than the bare minimum of CSS needed. This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewh…

> This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere,

Why not use native css variables?

> Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening

Again, if you are using plain css I don't think this is an issue. With any modern build system it will spit out css file for that build, right?

> After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.

I think this sentence says it all: Any framework will be "more efficient and maintainable" once learned, even if "took quite a bit".

For tailwind I think it's an abstraction too far, but that's a decision we all do ourselves.

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

#296
From an accessibility point of view and working on an accessibility audit, using tailwind and utility classes can be really difficult. Working with tools like Siteimprove, will ask if there are matching selectors for things that may be similar, and idm there aren't you may find yourself, looking at each page separately, with that component in it.

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

#297

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

It does make that easier for people to choose to do, but I would argue that it shouldn’t be held against tailwind that people do this. Also, sorry, but I’m doubtful that when using CSS that no markup would be changed to better accommodate the final layout…just like tailwind?

If the first tool in your tool chest is to change the markup, then it doesn’t matter which method of styling you apply. If your first goal is clean markup and accessibility…then It doesn’t matter which method of styling you apply.

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

#298

Tailwind isn't just a framework; it's a design system. The creators of Tailwind wrote the brilliant book "Refactoring UI" [0], which presents a systematic design system, introducing ideas such a type-scales, color-scales, spacing, and tactics to minimizes the cognitive burden on the designer by forcing design choices. The ideas presented in this book basically are tailwind classes! When you build with Tailwind, every…

Both refactoring UI's ideas you mentioned and component css far predate tailwind.

Atomic CSS really solves problems that only exist if you're holding the tool wrong, in my humble hot take.

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

#299
post #156

Earlier quoted context omitted.

> Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference. Erm... what now? That's so off-the-wall that I can't even wrap my head around your meaning. Are you trying to argue that because, say, a conventional CSS file has "border:1px" in multiple places, this is somehow equivalent to the Tailwind approach of making a "b1p" class th…

Yes, that's exactly what I'm saying. You don't end up needing a semantic class like .widget since you likely already have a Widget component in your codebase. Essentially: .widget { border: 1px; } ... const Widget = () => ( ); vs const Widget = () => ( ); You keep saying this is an abuse of CSS and that's not how it was meant to be used, but why is that so important?

In any real application you will have far fewer semantic class names than combinations of style properties. Working with concepts is vastly easier than trying to remember the specific property differences between concept A and concept B.

Obviously, a real application will have more than one css property. Also, your widgets will share styles, usually in a fairly obvious hierarchical way. And your designers will want them all to be consistent.

In this world, it’s far easier to remember that a widget is “.widget”, and that “.rounded-widget” is for the round version of that”, than it is to remember that the former concept is “.b1p .m5 .ib .xyz .pdq .foo” while the latter is “.b1p .m5 .p2 .br10 .xyz .bar”

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

#300
post #278

Earlier quoted context omitted.

Can you provide an example of well written components that use Tailwind? Genuinely curious to see what that looks like.

have a look at tailwind ui to start: https://tailwindcss.com/plus

This is ironic to me because Tailwind’s paid templates are absolutely terrible div soup.
Post reply on HN