Live data from Hacker News

Moving away from Tailwind, and learning to structure my CSS

jvns.ca

271–280 of 435 posts

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

#271

Earlier quoted context omitted.

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…

It’s not Tailwind the tech, it’s the ergonomics of the tool. Tailwind’s design loop encourages “let me add a div so I have a place for my CSS class”. I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design. Basic HTML authoring is good practice for many reasons.

Screen readers do not announce divs. They only read from the AOM.

A itself is treated as a generic, transparent box. It doesn't get keyboard focus, and it isn't added to the screen reader's elements list (like headings, links, or landmarks).

> I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.

Tell me how often screen readers announce divs that have no role attributes. You are continuing to spread misinformation

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

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

what unique flaws does tailwind have that the OP pointed out? my entire reply was pointing out that fact and that tailwind (or any tool) doesn't force you to build "div soup apps", which is factually correct.

> If you have some unique feature to tailwind that you think makes it better than the rest, you should share that.

i did mention some but you'll then claim it's not unique because some other tool has it so...

> Everything you have listed is also accomplished by all the other CSS frameworks

not true. most frameworks for example do not have nearly the universal familiarity tailwind has, for example. tailwind has a build tool that strips unused selectors and can dynamically build new classes (eg "w-[20rem]") if needed. do all frameworks do that? maybe a few but most do not

> sounds like tailwind is simply the main one you have experience with.

i've used so many frameworks i cannot count them on my hands (and feet even). i've settled on tailwind because it solves problems better than any other tool i've used. that's my preference yes, but your implication that i'm just using it because it's the only thing i know is so far from the truth it's comical

do yourself a favor and stop assuming people choosing tailwind don't know what they're doing

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

#273

Earlier quoted context omitted.

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

The structure of your CSS, and the structure of your divs, do not affect AT experience. This is misinformation.

As mentioned below:

A itself is treated as a generic, transparent box. It doesn't get keyboard focus, and it isn't added to the screen reader's elements list (like headings, links, or landmarks).

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

#274
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…

> nothing about tailwind forces you to build inaccessible or "div soup" apps https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... So what if it does not "force" you?

i've worked on about 8 different production teams/products with tailwind and none were div soup. does that prove your claim wrong? at what point would you accept maybe some people know how to use html AND tailwind together?

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

#275
post #245

Earlier quoted context omitted.

I separate those too. Queries get their own file. Sometimes their own framework.

Sorry maybe that wasn’t the best example. It’s not really about separation of files. But how they connect. In sql your code may be in a seperate file but your app code is still clearly calling the sql. The inlining vs not inlining is just abstraction. You could use a function, or a separate file or not, a different language or not. But there is a clear single call chain at the points where that behaviour is being app…

> With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.

There's only one algorithm, the cascade. And it's described here[0].

And just like any code you write, try not to write complex selectors. If you're not sure two styles are equal, it's better to write two different rules. And just like styling works in any system, you go from generic (standard html elements) to very specific ones (the link in the hero section of the about page)

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Casc...

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

#277
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…

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

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

you read a lot into me choosing "application" instead of using "website". for the record i think tailwind works great for both and it actively using in in a many tens of thousands of LOC web "application" and managing a team using it on a fortune 100 mostly static website that gets millions of views a month.

tailwind works great for both and in fact i'd argue works even better on "static" sites because it's efficient bundles and selector compression over the wire. we don't ship a single byte of css we don't use, thus saving on wasted bandwidth and increasing our SEO/page speeds

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

i love when people are so confident other people don't have valid reasons to use tools. real "junior dev" vibes, my friend

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

how many "bespoke" css projects have you worked on? i've works on MANY. nearly all of them suck to get familiar with and to not risk messing up some weird selector hierarchy you weren't aware of. can it be done well? sure, but it's incredibly rare and often only happens on smaller teams/projects. scaling out bespoke css sites becomes increasingly challenging as you scale in LoC and team size.

on the other hand, give me any tailwind project and i can start contributing immediately

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

ready-made stylesheets? do you mean like a css/html template?

the ecosystem means IDEs work well with it, there are lots of help resources, llms are trained on them heavily, you can find devs who know how to be productive with it, etc.

you can be very familiar with css but struggle within some bespoke framework with the fact that you can structure css in near infinite ways. tailwind gives you a consistent structure and approach across projects

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

#278
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 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

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

#279
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…

> nothing about tailwind forces you to build inaccessible or "div soup" apps Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason. While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch o…

svelte does a decent job around warning about inaccessible components / elements. they're mostly focused on accessibility but in a way that's what really matters outside of SEO

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

#280

Earlier quoted context omitted.

Sorry maybe that wasn’t the best example. It’s not really about separation of files. But how they connect. In sql your code may be in a seperate file but your app code is still clearly calling the sql. The inlining vs not inlining is just abstraction. You could use a function, or a separate file or not, a different language or not. But there is a clear single call chain at the points where that behaviour is being app…

> With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply. There's only one algorithm, the cascade. And it's described here[0]. And just like any code you write, try not to write complex selectors. If you're not sure two styles are equal, it's better to write two different rules. And just like styling works in any system, you go from generic (standard html elements) to very…

that’s exactly the part that is anti locality of behaviour.

I don’t want/need cascade. I only care about components and building up from them. And I would rather have it be explicit over implicit and scoped/encapsulated.

Call it composition over cascade.

To be clear I think it’s possible to do this without tailwind. And tailwind has other out of the box features/opinions.

But it works well enough without too much friction.

Post reply on HN