Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

371–380 of 435 posts

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

#371

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

> HTML is marking up the meaning of the document.

Is this true at all anymore, except for SEO optimized sites/content?

For apps, it’s all layout, isn’t it — and HTML, JS, CSS have all evolved heavily to support UI-first, haven’t they?

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

#372
When an agent writes a component, the styles come along with the JSX. "flex items-center gap-4 bg-purple-600 rounded-lg" doesn’t require any mental context switch to a separate stylesheet file. Custom classes force you into a separate file for each component; utility classes keep the style information close at hand.

The other thing Tailwind stops from happening: class name bloat. In its absence, agents invent classes such as "card-header-inner", "feature-block-content", "sidebar-item-wrapper" – all separate naming choices. After a few months of development, you accumulate hundreds of classes that are not owned by anyone. The limit placed by Tailwind is in its vocabulary; there are no names to invent. This trade-off described by Julia exists. It's just articulated a bit differently.

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

#373
post #310

Earlier quoted context omitted.

There’s absolutely no tension between locality of behavior and separation of concerns in CSS: you’re putting styles on the elements in the document . The styles are defined elsewhere. It’s like arguing that all of your source code should go in one big file because one file is less than two files, which means greater localization.

Its arguing that that source code that affects the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse. Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path. Like you would want to init a variable closer to its usage, Or that having a 100 wra…

> the behaviour of something should be easily discoverable from the point/points its behaviour affects. or alternatively more indirection/obfuscation is worse.

This is why I'm not that big of a fan of Tailwind and similar frameworks. To me it feels like they introduce yet another language into the mix. It adds all sorts of classes directly to the html, but now I need to understand what all of those mean. If I write my own CSS, I generally just have to look in one place to understand the styling of an element.

I think I feel kind of like that about overuse of annotations in Java. (Simple/obvious ones are fine, but not all are simple and obvious.)

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

#376
post #54

Earlier quoted context omitted.

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…

> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex. > placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors In my opinion, it's the opposit…

> It actually increases cognitive load because you have to account for CSS in two different locations.

How does doing everything in-line (one place) cause two locations?

Thanks.

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

#377
post #18

Earlier quoted context omitted.

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

> but if we get our first blind user I will gladly make some admends to make it more usable for them. Isn't this slightly backwards? Why would blind users sign up if the platform isn't usable for them in the first place? It has to be usable for them for them to become users :)

Notably, this is also how most businesses treat their sighted end-users…

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

#378
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?

Perhaps an accessible URL you’re associated with in your bio, to bolster your point?

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

#379
post #148

Earlier quoted context omitted.

Picking subsets of customers to focus on is a totally standard part of running a startup or company in general, so this is not really news or any kind of threat. You might as well tell me the suburban moms are not going to buy my developer tool because I've personally slighted them with the branding. Why would I care? I made my decisions knowing this. In fact ditching low RoI customers is incredibly common and good s…

This is just admitting that your product is small and unimportant.

As if that’s a bad thing.

Lifestyle businesses are king.

Who wants to be important?

I’d rather be happy.

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

#380

Earlier quoted context omitted.

But why would I spend any time mastering this skill when we have AI now? Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary. Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.

I guarantee you no one is working on this.

A larger, monied AI service will almost certainly trot something like this out as proof of public good in the next few years,

even if it’s something they only notice they can do by accident,

or in a down news cycle.

Post reply on HN