Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

141–150 of 435 posts

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

#141
> I’m a lot better at CSS than I was when I started using Tailwind.

> I got curious about what writing more semantic HTML would feel like.

This is so relatable. In the beginning of my career, I used to add so many dependencies for things I did not know. But these days, I mostly work on removing dependencies because I'm a lot better at using the web platform. I treat the web platform and browser primitives as materials to build what I want rather than a blank canvas to paint things from scratch.

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

#143
post #45

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

Using tailwind doesn't lead to any inherent concession of accessibility. How do you come to that conclusion? If I look at their component library, they also do the work of including aria attributes for you https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr... (first exsmple with free code I've found). If we're not talking landing pages, which are more like digital brochures, I always start with markup and t…

Who said inherent. The design loop of “I need a div for my CSS class” is an ergonomic problem not a concession.

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

#144
post #142

Tailwind makes sense when you can use React Components to build a reusable design system. It is annoying as heck to use if you don't have that superstructure.

To add: I dont want to go back to writing semantic css.. no thanks - I dont go in time-back machines. This is a mess.

Just using tailwind and anchoring around a design system like shadcn is just way easier for a team to align around than somebodys made up css language.

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

#145

Earlier quoted context omitted.

> Tailwind instead pushes the dev into a CSS-first approach. You think about the Tailwind classes you want, and then throw yet-another-div into the DOM just to have an element to hang your classes on. To be fair plopping a `div` everywhere started way before Tailwind. I blame React and the mess that is CSS in JS for this.

It did for sure. And Tailwind absolutely doesn’t need to be done this way. I think this is a correlation-not-causation issue

I disagree. With Tailwind you think in nested classes which ergonomically encourages “I need a div for this class”.

Very similar to early React where every component had to return a single real parent element (now you can return a fragment) so people chose div.

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

#146
The only problem with Tailwind is its syntax. It is anti-CSS. It is confusing and takes time to get used to. Heck, people even wrote cheat sheets. That makes adoption wrong, because people install it just because everyone else uses it or because the current thing brings it in. A long time ago, before Tailwind, I was writing true, pure functional CSS https://www.fcss.club/manifesto, and I never came back to the old OOCSS or BEM style of structuring all the styles in a project. Components helped a lot with that decision. Today, functional CSS does not make sense only if your website is truly, truly simple. But if your application is more complex, FCSS outshines everything else: speed, rendering, simplicity https://www.fcss.club/syntax, and weightlessness.

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

#147

Earlier quoted context omitted.

I’ve mentioned this before here, but originally I was against Tailwind because it breaks the Cascading part of CSS, however I think a lot of websites lately work better with “locally scoped” styles as there are just so many different components that many things just dont need to follow a global style sheet. So now I usually reach for tailwind first, unless is a relatively simple vanilla html site

Global styles are like global state in software: They're best avoided.

Global state is bad because it’s mutable. Global styles are not mutable.

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

#148
post #116
post #68

Earlier quoted context omitted.

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.

You just told a bunch of potential and current customers that they're not worth the ROI. Pretty sure they'll remember that, and they'll talk about it a lot.

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 startup advice.

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

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

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

How will you know if they are unable to use your site? They'll just leave.

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

#150
post #45

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

Using tailwind doesn't lead to any inherent concession of accessibility. How do you come to that conclusion? If I look at their component library, they also do the work of including aria attributes for you https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr... (first exsmple with free code I've found). If we're not talking landing pages, which are more like digital brochures, I always start with markup and t…

> If I look at their component library, they also do the work of including aria attributes for you

Using ARIA attributes instead of semantic elements is bad for accessibility.

Post reply on HN