Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

Post reply on HN
Print view View original

171–180 of 435 posts

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

#171

Post by slashdave »

codethief wrote: post #124
arealaccount wrote: post #122

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.

Says the engineer and not the designer

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

#172

Post by rhdunn »

xigoi wrote: post #150
mhitza wrote: post #45

Earlier quoted context omitted.

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.

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

[1] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

[2] https://www.w3.org/WAI/ARIA/apg/patterns/

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

#173

Post by zelphirkalt »

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 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 on Tailwind for the last few years is precisely because it enables me to build more robust application styling.

I think herein lies at least part of the problem of the web these days: Most websites don't need to be applications, and are needlessly made to be applications, often even SPAs instead of simply being mostly informational pages, in turn putting different requirements for styling onto the project.

> [...] jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/apps

There is no need for frameworks. Well structured and scoped CSS can handle it all.

> add to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind

What if not that does CSS already offer? I don't see how normal CSS does not already do that. No additional thingamabob needed.

> very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teams

Tons of ready-made stylesheets out there to use for teams. What more of an "ecosystem" do I need to style a web page? Why do I need an ecosystem? Is it not rather a tailwind self-induced need?

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

#174

Post by SkiFire13 »

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

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

IMO this is the fundamental problem with HTML and CSS. You'll always have some part of the styling in the HTML due to needing extra divs and spans. At that point splitting the styling outside into the CSS splits your attention and Tailwind "solves" that by moving everything back into HTML.

Note that I don't like Tailwind, but I would rather have a way of styling that does not need to rely on the existance of extra divs and spans to work.

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

#175

Post by thiht »

zamalek wrote: post #56

What I don't get about tailwind is: why not just use the style attribute at the point?

With Tailwind:
With style:
Now more interestingly, Tailwind with hover and focus styles:
That’s not possible with the style attribute.

Even more interesting with Tailwind, a div with dark mode and responsive styles:
That’s not possible either with the style attribute.

Now your first instinct might be to "that’s unreadable", but keep in mind HOW you actually read and write this code. You’re not actually reading it to understand what it does like you do with iterative code. You see how the browser renders it, and you just adapt the code. Tailwind code is mostly write-only and maintained by viewing what the component looks like. This code doesn’t need to be reusable either, the whole component needs to be. The Tailwind code inside is unique.

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

#176

Post by anydigital »

BoredPositron wrote: post #14

I am so happy that the only time I have to touch css anymore is for simple internal tools and pico is usually enough for them.

+1 for Pico CSS! It’s fantastic.

We actually loved it so much that we've taken over maintenance for a fork here: https://github.com/anyblades/pico

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

#177

Post by raincole »

xigoi wrote: post #163
raincole wrote: post #71

I think the (misuse of) so-called "separation of concerns" has been the most harmful thing that happened in web front end development. HTML can CSS are the same kind of concerns: the presentation layer. The idea that HTML is purely semantic and has nothing to do with presentation is just burying the head in the sand. Separating HTML and CSS into different files is just like separating a bunch of methods/functions int…

HTML is the content layer. CSS is the presentation layer.

Yes, this is the exact harmful idea that I was talking about. If this were true than there would be no 'reader mode' in browser. Or the reader mode would not modify the html at all.

What you see in reader mode is the content layer. HTML is a part of the presentation layer.

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

#179

Post by bsoles »

flossly wrote: post #18
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.

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.

I have heard "we don't have blind customers" argument many times before. Apart from ethical issues that this raises, ADA requirements, technically, don't care if you have blind users or not. Accessibility is still required...

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

#180

Post by esseph »

0x3f wrote: post #148
esseph wrote: post #116

Earlier quoted context omitted.

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

I suspect as the years change and you continue to get older you will likely revisit this idea mentally.

But you do you, boo

Post reply on HN