Moving away from Tailwind, and learning to structure my CSS • Hacker News Board

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

#201

Post by troupo » Sat, May 16, 2026, 7:08 PM UTC

xigoi wrote: post #153

troupo wrote: post #80

Earlier quoted context omitted.

> HTML is marking up the meaning of the document. You should start there. Then style with CSS. If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first). > Tailwind instead pushes the dev into a CSS-first approach. You're putting the cart before the horse. Or forgetting either the cart or the horse. Tailwind doesn't force anything…

> Oh no! And what are the opening examples on any of the "proper pure-as-god-intended CSS" sites? The first example on https://developer.mozilla.org/en-US/docs/Learn_web_developme... : Instructions for life: Eat Sleep Repeat p { font-family: sans-serif; color: red; } li { background-color: greenyellow; border: 1px solid black; margin-bottom: 5px; } No divs and spans in sight.

True! And Mozilla is one of the good guys.

What I should've said in my hastily written comment should have been: "and other implementations of the same (or other) functionality isn't divs and spans?"

I think my only true criticisms for Tailwind example would be:

- should've probably used h2/h3 for card titles. Though this is dependent on where and how the card is used

- should've done more with the meta (number / date). But in a real world these would probably still be spans (for example, to mark them in different colors etc.)

HTML doesn't have a card element. So when you create one, you... use whatever's available. And divs and spans in HTML+CSS literally exist to manipulate layout and text.

BTW, my favorite accessible card is this one: https://inclusive-components.design/cards/ And it's probably even more weird. Demo: https://heydon.github.io/Inclusive-Components/cards-redundan... (check the CSS also)

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

#202

Post by [deleted] » Sat, May 16, 2026, 7:10 PM UTC

ghurtado wrote: post #107

danaw wrote: 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…

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

[deleted]

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

#203

Post by extra88 » Sat, May 16, 2026, 7:15 PM UTC

zero_shift wrote: post #59

TonyAlicea10 wrote: post #13

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.

What does Tailwind have to do with accessibility? Most significant HTML markup is block level elements. The CSS is completely orthogonal. I feel like old-school frontend devs bring up accessibility as a kind of bogeyman. It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until s…

I'm not familiar with that old tale about Zeldman. It's true that assistive technologies don't know about CSS class names but CSS absolutely can affect a non-sighted screen reader user's experience.

I don't use Tailwind so I don't know if it makes it easier or harder to do the right thing when needing to hide something from everyone or only visually hiding something. Because it's CSS, it can't take care of only hiding something from assistive technologies.

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

#204

Post by SwiftyBug » Sat, May 16, 2026, 7:15 PM UTC

One approach I've been really starting to enjoy is to use use Tailwind alongside scoped styles (in Svelte and Vue). This keeps template pollution minimal while still allowing for the conveniences Tailwind brings:

  
      +
      {{ count }}
  
  
  
  @reference "tailwindcss"
  
  .counter-component {
      @apply flex items-center gap-2;
  
      button {
          @apply bg-gray-800 text-white;
      }
  
      .count {
          @apply italic text-teal-500;
  
          &[data-is-even="true"] {
              @apply text-rose-500;
          }
      }
  }

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

#205

Post by troupo » Sat, May 16, 2026, 7:20 PM UTC

TonyAlicea10 wrote: post #152

7bit wrote: post #20

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. I wholeheartedly disagree. That mindset is not caused by Tailwind, but by being ignorant. You can perfectly create an HTML document with semantic meaning and the add Tailwind just as any other CSS framework or pure CSS…

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 called "elements of last reserve" because it's only true if you remember that HTML is, has been, and forever will be a tool to display static text, badly. That's why you have article, section, p, and other text-oriented elements. But the moment you want something beyond that? Welcome to divs.

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

#206

Post by bthallplz » Sat, May 16, 2026, 7:23 PM UTC

xrd wrote: post #92

I really, really love Julia Evans writing. She writes from a place of vulnerability and honesty. Most people write to sound smart and she writes to say "I don't know it all but there are some things I discovered I want to share." I almost feel like she writes to share things with people she loves, even though she doesn't know them directly. She spoke alongside Randall Munroe at the last Strange Loop (RIP). Some peopl…

> I almost feel like she writes to share things with people she loves, even though she doesn't know them directly.

Thank you for articulating this!

I'm not Julia, but I'd just like to put down here that this is pretty much my philosophy for public speaking/giving presentations, and I have been trying to instill it in some coworkers who struggle with presentations. It's a great privilege to be able to convey to one's peers and loved ones things that you're (likely) a bit more familiar with than they are and which may help them with some matter.

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

#207

Post by simsation » Sat, May 16, 2026, 7:24 PM UTC

ramesh31 wrote: post #86

mgraczyk wrote: post #82

Earlier quoted context omitted.

CSS is badly designed and uses a confusing, separate DSL with arbitrary rules designed before the Internet was widely used, before web apps existed, before smartphones etc It's trash and throwing it out is good. Not learning it is good. Tailwind is a solution to a real problem. More importantly, AI is good at it already and it's unlikely humans will need to understand HTML/CSS at all within a year or two. There's no…

>It's trash and throwing it out is good. Not learning it is good. Tailwind is a solution to a real problem. Yup. Spent a decade of my career writing CSS every day, I was what you would call a "guru" and have written easily hundreds of thousands of lines of it over the years. Haven't touched a class or a stylesheet in nearly a year now, and probably never will again. Good riddance.

Same for me, I started web development with Netscape and IE5, and all the browser specific CSS declarations and media queries, checking on so many different browsers. Then all the trouble with positioning by inline blocks/float, then flex boxes. Now AI does all the HTML structure and CSS. Never have to do it again.

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

#208

Post by kcrwfrd_ » Sat, May 16, 2026, 7:25 PM UTC

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…

I’ve also been writing CSS professionally for nearly 20 years and am a big fan of tailwind.

The ergonomics in my day to day work are quite nice. To me, the better boundary of abstraction shifted to components, rather than the html/css/js “separation of concerns” that some of the older folks still like to parrot.

However, take a look at the markup and styling for the https://maps.apple.com/ web property.

I can’t deny that it’s quite beautiful and easy to holistically understand. Especially when it comes to the responsive styling—which is when I tend to find tailwind most awkward.

It’s my favorite example of “traditional” CSS structure in recent memory that has given me some pause when it comes to Tailwind.

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

#209

Post by troupo » Sat, May 16, 2026, 7:26 PM UTC

timr wrote: post #101

pverheggen wrote: post #90

Earlier quoted context omitted.

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

> but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.

Yes. And as 30 years of CSS show, it's not enough.

> Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place.

It's not repeated all over the place, because in your codebase you have a single place where component A is defined. A single place where component B is defined etc.

I don't see you complaining about having to repeat the same CSS properties (padding, margin, display etc. + responsive styles + hover/disabled etc.) for half of the components when writing vanilla classes.

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

#210

Post by extra88 » Sat, May 16, 2026, 7:27 PM UTC

rhdunn wrote: post #172

xigoi wrote: post #150

Earlier quoted context omitted.

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

How are ARIA roles/attributes bad for accessibility? Sure, if there is a HTML element that works then use it, but not every UX pattern is expressible in HTML without specifying roles/attributes (e.g. tabs [1]) and not all browsers support recent HTML elements/attributes (such as using details/summary for accordions). ARIA patterns [2] has a list of examples for UX components and their examples specify/use ARIA roles/…

WAI's APG patterns exist to document how ARIA attributes should work, they don't advocate for them to be used in place HTML elements. They also don't test to confirm that they actually work in browsers or with assistive technologies (some specific patterns are fine). For web developers, they're helpful for documenting expected keyboard interaction support and other norms.

Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...