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

Moving away from Tailwind, and learning to structure my CSS (jvns.ca)

698 points by mpweiher 24 days ago | hide | past | favorite | 397 comments

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. 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 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.Tailwind makes you worse as a web developer from a skill standpoint, since part of your skill should be to produce future-proof readable HTML and CSS that it usable by all users and generally matches the HTML and CSS specs. But devs haven't cared about that for years, so it makes sense that Tailwind got so popular. It solved the "I'm building React components" approach to HTML and CSS authoring and codified div soup as a desirable outcome.Tailwind clearly never cared about any of this. The opening example on Tailwind's website is nothing but divs and spans. It's proven to be a terrible education for new developers, and has contributed to the div soup that LLMs will output unless nudged and begged to do otherwise.

| danaw 23 days ago | parent | next [–] 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" appscan tailwind be used poorly? absolutely. but that's true of any tooli'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.tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors affecting styles unintentionally and really aids in debugging. jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/appsadd to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind and a very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teamstailwind is like most tools; it can be used well or poorly depending on who is using it

| alwillis 23 days ago | root | parent | next [–]

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 selectorsIn my opinion, it's the opposite. Besides the obvious violation of DRY and the separation of concerns, inline CSS can't be cached and it creates a lot of noise when using dev tools for debugging. It actually increases cognitive load because you have to account for CSS in two different locations.Lots of people use Tailwind because they don't want to deal with the cascade, usually because they never learned it properly. Sure, back in the day, the web platform didn't provide much built-in support for addressing side effects of the cascade, but now we have @layer and @scope to control the cascade.Tailwind uses a remnant of '90s web development (inline CSS) and built an entire framework around it. I get why it appeals to some people: it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts.

| danaw 23 days ago | root | parent | next [–]

Sure, it's easy to overthink things but most of the time, it's not that complex. then you sir are the one that have not worked on complex projects. i'm currently the lead on a design system for a fortune 100 company with nearly 100 block level components and many other smaller elements. responsive, multi-theme/site support, animations, accessibility, robust interactivity, etc. not even a button or link is simple when you're building complex systems tailwind allows us to reason more clearly about these often very complex components> inline CSS can't be cachedthis shows your lack of understanding. first off, it's not inline css, they're classes and thus you only ever define "flex" in one place vs many many places in non-utility css approaches. in fact, sorted html classes are compressible over the wire so you're doubly wrong.> because they never learned it properly condescending> it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts also condescending and just such a boring, over used argument i always hear from haters of tailwind maybe try and counter my arguments without the attitude? maybe understand seasoned veterans of css might have their reasons to choose it?

| 4rt 22 days ago | root | parent | next [–] if you're writing class="flex-inline width-30 font-large" it's even worse than inline css because it has an abstraction layer and dependencies.just write css, tailwind has always been total junk.

| array_key_first 19 days ago | root | parent | next [–] There are legitimate problems with using CSS, especially in a large team setting. I think we all have experience with append-only stylesheets. That's what tailwind addresses.

| amazingamazing 23 days ago | root | parent | prev | next [–] I have used tailwind and tachyons and they are fine. I do winder though it seems like you end up being stuck with them. How would you migrate to traditional CSS without effectively rewriting all of your css?I also wonder if it is necessary still with css modules and the fact web frameworks allow for scoped css per component.

| faefox 22 days ago | root | parent | next [–] Tailwind is just CSS so there's no lock-in to speak of and no migration necessary. If you had a specific instance where Tailwind wasn't a good fit you can just hand-write as needed.Sure, if you wanted to stop using Tailwind altogether you would have a lot of rewriting to do but I'm not sure how that's uniquely different or worse than, say, migrating a project from React to Angular.

| ricw 23 days ago | root | parent | prev | next [–] I disagree with that conclusion. I see tailwind as a cleaner more succinct version of css that is much easier to manage and add features too.Sure it’s not as dry, but I’ve been bitten in this regard because css framework and templates are so intransparent, preventing me from simply changing padding or margin.CSS is too detailed and too verbose. Frameworks like bootstrap are too high level and don’t give enough control. Tailwind hits the sweet spot whilst allowing me to be detailed if I want to. It allows me to just get it done.

| jampekka 23 days ago | root | parent | next [–]

Sure it’s not as dry, but I’ve been bitten in this regard because css framework and templates are so intransparent, preventing me from simply changing padding or margin.How does this happen? You can always override css values. Either by ordering, !important, inline or, to make very sure, with inline !important.

| sntran 22 days ago | root | parent | next [–] When you inherit a front-end project for the Nth time, those !important become a nightmare.

| abustamam 22 days ago | root | parent | prev | next [–] I found that once I started needing to use inline styles or !important or in-line important, I was in for a world of hurt and felt sorry for whoever maintained the project after me.

| christophilus 23 days ago | root | parent | prev | next [–] With CSS names are global. You have to be careful not to accidentally create a class that conflicts with another one used elsewhere in a different context. You have to worry about whether modifying your class will have downstream effects on elements you weren’t intending to impact. It’s a giant pain. I’ve done it by hand for around 20 years before switching to Tailwind.Can vanilla CSS be used for a complex app? Yes. But, it takes discipline, and I only have a limited amount of that. I’d rather spend my discipline budget on other things.That said, nested selectors and CSS variables have gone a long way towards making the vanilla experience much more pleasant. I may have to give it a shot on a side project one of these days.

| yawaramin 23 days ago | root | parent | next [–]

With CSS names are global.Not necessarily. Nested selectors make it pretty easy to apply styles in a modularized way. See https://rstacruz.github.io/rscss/

| alwillis 21 days ago | root | parent | next [–]

With CSS names are global.You can limit selectors (not custom properties) to a subtree by using @scope.On the horizon is @function [1] where custom properties can be local to the function.[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

With CSS names are global.In your "programmatic" code (your JS/TS, python, C++, whatever..) your classes are global. Even if the language supports flexible namespaces, or module scoping, you still have to take great care naming because reusing a name will cause you confusion. Giving two things the same name makes them harder to import, and risks clashes and bugs.No-one complains about this. This is just how you code in all those other languages.

| jakelazaroff 23 days ago | root | parent | next [–] In "programmatic" code, declaring two classes with the same name in the same namespace is generally either some sort of syntax error or one will "shadow" the other; it doesn't just silently merge the behavior of both classes.

| the_other 22 days ago | root | parent | next [–] TypeScript interfaces just merge. You can aet any property name you like on a plain JS object, at any time.The CSS version is a risk, for sure. The dev tools in all the main browsers will tell you where the extension happens and show yiu the order the complecting rules are applied, so it’s fairly easy to debug. Bugs/misbehaving code is usually a problem of structure. In other languages, we take on the need to apply structure; just do the same with CSS.The mechanism that allows this merging behavior is the means by which intentional reuse is composed. It allows yiu to set general and specific rules sets. This seems conceptually similar to OO classes and subclasses, to me.

| 1shooner 23 days ago | root | parent | next [–] This is (imo) the most valid argument for Tailwind: the UI semantics of "hero" "card" etc aren't put in CSS, they're put in the module. Modules are typically designed for this encapsulation, and CSS was not.

| bobthepanda 23 days ago | root | parent | next [–] when i say css modules i mean something more akin to https://css-tricks.com/css-modules-part-1-need/

You have to be careful not to accidentally create a class that conflicts with another one used elsewhere in a different context.Has your tried using the cascading part of the language?

| wetoastfood 23 days ago | root | parent | prev | next [–] Your framing assumes incompetence across the board which is unlikely to be true for a framework of its popularity. Consider instead competent people are working on projects with different needs and they’ve recognized there are trade offs to both approaches and still decided Tailwind makes sense in their situation.

| danaw 23 days ago | root | parent | next [–] have you ever built a complex web app? with you're snarky reply my assumption is noany experienced developer without a condescending attitude can recognize all types of programming require skill and nuance to build good software, no matter the target

| bobthepanda 23 days ago | root | parent | prev | next [–] To be honest, CSS had the cascade but also had horrible tools for actually managing the cascade for a long time.If CSS had nesting, variables, media queries, the other nice selector queries like :has, and modules out of the gate, we likely would have not needed much of the tooling like tailwind that eventually got built to manage it all with less boilerplate. We built the tools because even when these features rolled out they came in fits and starts so you couldn’t adopt it without polyfills and whatnot.

| wild_egg 23 days ago | root | parent | next [–] When you say modules, is that @scope or something else? I can't find any reference to a native thing called modules but this seems to fill the same role.

| bobthepanda 20 days ago | root | parent | next [–] So I guess modules is not native, but in a fair amount of JSX oriented systems there is a .modules.css file extension that build steps will recognize and automatically namespace with an ID linked to a JSX component.https://github.com/css-modules/css-modules

inline CSS can't be cachedCan you elaborate what the problem is? What is it you want to cache?> and it creates a lot of noise when using dev tools for debugging.I don’t think so. The element styles have an own section (assuming you debug the applied styles)> It actually increases cognitive load because you have to account for CSS in two different locations.Same applies to no tailwind. You need to account for the html (is parent block / inline / …) anyway.

| array_key_first 19 days ago | root | parent | prev | next [–] Tailwind violates DRY but DRY is also not a hard and fast rule. The danger with DRY is that it can force you to build abstraction towers that are difficult to reason about, especially in a static context. And that's where we see the power of Tailwind: I can look at any element and immediately see it's styling. The same is not true with classic CSS, which is additional cognitive load.Also, DRY can still be somewhat achieved with tailwind by using reusable components, in whatever framework you're using. It could be React, but it could even be blade components in a traditional SSR Laravel app.

| RcouF1uZ4gsC 23 days ago | root | parent | prev | next [–] Premature DRY and premature attempt at separation of concerns have resulted in absolutely horrible spaghetti code in too many code bases.Many times it's fine to repeat yourself. Many times it's fine for a component to cross multiple concerns.

| hansvm 23 days ago | root | parent | next [–] DRY is critically important as it pertains to correctness. If DRY is hard to achieve for technical reasons then back-reference comments and whatnot can suffice, but you really do want only one owner for each meaningful fact in your codebase.That's not to be confused with syntactic similarity. I largely don't care if you have ten different identical circular buffer implementations, so long as semantically it's correct that when one changes the others don't. Depending on the language maybe it would make sense to use type aliases or extract some common subcomponents or something, but duplication itself isn't a problem.

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.

inline CSS can't be cachedClasses are now in-line styling? Why are you doubling down on a subject you're obviously not familiar with?And the separation of concerns argument is always strange to me because in React, my concern is the component.

| _the_inflator 22 days ago | root | parent | prev | next [–] Trashing without offering a hands down solution is academic and therefore can safely be rejected.Please show me only ten of the SaaS you lead that rely on your CSS framework.You must have one, because you talk about structure and premises. Orderly put and repeatedly applied you get a framework.I doubt it.I registered my first domain 1997. I love to debate anyone coming up with a clever not so clever theoretical argument against Tailwind.Where are all the you might not need jQuery JavaScript guys?The same goes for Tailwind.And just as a reminder: CSS started as so called separation of markup and design. A zen garden tried to proof this but only showed how one cannot exist without the other.Loose coupling as the saying goes.Since the ACID test CSS went from some proposals to a stunning black hole of finally receiving differential treatment with the level nomenclature.And you besides all incompatibility issues and different browsers still think that you really grasp CSS or even know how to apply it semantically correct even though by matter of fact many concepts feature bogus terminology due to compatibility issues?I would love to interview you regarding edge cases. Do you get box models? Collapsing markings? Floats? Clearfix? Order of application?Print layouts? Views vs fluid design?Really, attacking Tailwind is the same as “Let’s build our own Google” trope. It shows lack of competence.

| joquarky 22 days ago | root | parent | next [–]

love to debate anyone coming up with a clever not so clever theoretical argument against Tailwind.Given your attitude (see your last sentence for a prime example), why would anyone want to debate you?

| TonyAlicea10 23 days ago | root | parent | prev | next [–] If a tool’s design makes it easy to cut myself, the response is not “people have been cutting themselves for years”.There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one.It’s ergonomics encourage adding div elements to support styles. It’s the core design loop.You’re conflating “forces to” and “ergonomically encouraged”.

| danaw 23 days ago | root | parent | next [–] i just don't agree tailwind makes it any more easy to make div soup than any other approach. if you don't care or know how to build proper markup no style approach is going to save (or hinder) you

| eager_learner 22 days ago | root | parent | next [–] to solumunus: notice your comment downvoted? it appears someone who is against Tailwind downvotes all pro-Tailwind comments. I think i know who- and will reciprocate in kind.

| kcrwfrd_ 23 days ago | root | parent | prev | next [–] 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.

| paulhebert 23 days ago | root | parent | next [–] For what it’s worth I like to encapsulate things in components and still separate out the CSS from the markup.In my mind it’s the best of both worlds. Vue makes it easy. I think CSS modules in React work similarly

can tailwind be used poorly? absolutely. but that's true of any toolCan 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.Everything you have listed is also accomplished by all the other CSS frameworks, so it almost sounds like tailwind is simply the main one you have experience with.

| csallen 23 days ago | root | parent | next [–] _> 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._But this isn't a unique flaw for Tailwind. I've been coding with CSS since the late '90s and seen plenty of people throw yet-another-div onto the DOM just to have an element to hang their classes on. Done so myself plenty of times, too.People have been complaining about div soup for years and years before Tailwind ever came along.Plus I'm coding with Tailwind now, and almost never think about my classes before my HTML. Nothing about Tailwind in particular encourages you to do so. So I'm quite confused how this is a unique Tailwind flaw.

| danaw 23 days ago | root | parent | prev | next [–] 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 frameworksnot 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 comicaldo yourself a favor and stop assuming people choosing tailwind don't know what they're doing

| gf000 23 days ago | root | parent | prev | next [–] Even the root comment mentions the exact same failure mode:> 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).This is IMO not worse than vanilla CSS, and it's simply the only way to have customizable layouting in HTML.

| ruszki 23 days ago | root | parent | next [–] What are the cases when you have to use divs or spans solely for design? When I did such things, it’s only because I was sloppy, or didn’t know back then how to do it without it. But maybe, there are cases, I’ve just never encountered them yet.

| arealaccount 23 days ago | root | parent | prev | next [–] 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

| codethief 23 days ago | root | parent | next [–] Global styles are like global state in software: They're best avoided.

| xigoi 23 days ago | root | parent | next [–] Global state is bad because it’s mutable. Global styles are not mutable.

| IceDane 23 days ago | root | parent | next [–] No.. that's not the only reason.Global state is bad because it makes it hard to reason about your system. The global state can affect any part of it, or, focusing on the inverse which is probably better applied to global styles, any part of your system can depend on the global state.It's also weird to say "global styles are not mutable" - you're right, they're (generally) not mutable, at runtime. But they are mutable in the sense that your developers (you, or your colleagues, or someone in 3 years maintaining your code) can mutate them, and if large parts of your system are implicitly dependent on the CSS cascading properly and so on, then those changes can have unintended consequences.Of course, that can also apply to tailwind, to some extent. A developer can change a class (custom or otherwise) or the configuration - but at least it is very clear what is being changed and what parts will be affected (just grep).

| zelphirkalt 23 days ago | root | parent | next [–] With CSS unintended consequences are always problems of scoping things better. If I give semantically meaningful CSS classes to my semantic HTML and scope my rules to apply to their intended place in the pages, then unintended consequences don't happen. If I roll like: "Oh, I want this list to look differently, lets make a global scope ul/ol style!" then I am asking for trouble later on. When I write a CSS rule, I should always be thinking about the scope and whether my rules are truly something universally applicable to that scope.

| rtpg 23 days ago | root | parent | prev | next [–] Global styling done messily can override local styling. It’s the hardest kind of problem to reason about!I do think that stuff like bootstrap is generally good at avoiding this but it only takes a handful of improperly scoped high level CSS rules to cause awkward hard-to-fix pain much later on.

| skydhash 23 days ago | root | parent | next [–] Learn how cascading works, then learn how to use the web inspector. I'm using Firefox and the style panel list the the selectors used in order of priority. And you can filter by properties to see which one is overriding everything else (i.e the only one not crossed out).

| codethief 23 days ago | root | parent | next [–] What does the designer say?

| codethief 23 days ago | root | parent | next [–] No, you just need to scope your styles appropriately. See also my other comment: https://news.ycombinator.com/item?id=48161902

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

| danaw 23 days ago | root | parent | next [–] 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?

“…nothing about tailwind forces you to build inaccessible or "div soup" apps can tailwind be used poorly? absolutely. […] tailwind is like most tools; it can be used well or poorly depending on who is using it.”Hmm. Your reply refutes the div-soup accusation, but doesn’t provide any explanation.

| espadrine 22 days ago | root | parent | prev | next [–] Could you link to a project that you consider the best Tailwind use you know?I have a bias against Tailwind, admittedly because I saw some vibecoded Tailwind where each class was essentially equivalent to style="font-size: 4em; background-color: grey; display: flex;", all of which was repeated for each header.But that could be my bias; perhaps the right way to use is is DRY.

| sntran 22 days ago | root | parent | next [–] It's easy to look at one part of the HTML and see the Tailwind classes no different than inline styles.But if you have to use display: flex" in a lot of places, having theflex` utility is better. And there are tons of such utilities with Tailwind.

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/appsThere 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 tailwindWhat 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 teamsTons 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?

| danaw 23 days ago | root | parent | next [–]

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

nothing about tailwind forces you to build inaccessible or "div soup" appsTotally 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 on next did try to encourage better practices around things like accessibility. Make the path of least semantic HTML the path of least resistance and allow people to fall into the pit of success, ya know?

| ghurtado 23 days ago | root | parent | next [–] Nothing about programming forces anyone to do anything.That's never been a valid argument to dismiss criticism. It wasn't with Dreamweaver, any it wasn't with visual basic, and it isn't with Tailwind.Patterns matter. Best practices matter. Path of least resistance matters. Those are all choices you make when you develop a CSS framework. Some of those choices are good and some are bad.If none of those things mattered, them choosing a CSS framework would not matter at all.

| superfrank 23 days ago | root | parent | next [–]

Nothing about programming forces anyone to do anythingI see you've never written any Go

| TonyAlicea10 23 days ago | root | parent | prev | next [–] React encouraged this for years by requiring a single parent element being returned from all components. They also showed a div as the option of choice.They fixed this later with Fragments but the damage was done.

| danaw 23 days ago | root | parent | prev | next [–] 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

| danaw 23 days ago | root | parent | next [–] have a look at tailwind ui to start: https://tailwindcss.com/plus

| TonyAlicea10 23 days ago | root | parent | next [–] This is ironic to me because Tailwind’s paid templates are absolutely terrible div soup.

...

The problem with tailwind is that semantic HTML should be entirely free of styling decisions in the ideal case. That also goes for styling classes like flex flex-col etc.The way I would do it is to give the HTML some semantic meaning:

...

We can then decide how to treat section.info-for-nerds. Someone who reads the HTML immediately knows that this section is the bit that gives slightly too much information for nerds. That is what semantic means. The class adds meaning in a semantic sense, that helps to interpret the purpose of the element.Then in CSS you would just style the semantic.info-for-nerds text fully with flex, flex-col, the whole shabang. If there are other info boxes that share style adding a general info-box class is probably a good idea. Again, this is semantic. I don't say red-box. I say what the box is intended to mean , not how it looks.If you need the Infobox to look different in another context (or want to be sure your selector doesn't leak) you use the cascading bit of the language;

.page-article>article>section.info-for-nerds { ... }

.page-catalog>section.summary>section.info-for-nerds { ... }

Notice btw. that I also prefer to use semantic HTML elements like section, article, main, aside over generic ones like div. Using these well may even mean you don't need any classes at all. If you have three nested divs classes are the only way to k ow which one is the article. If you have main containing article containing section, that may literally be all the info you need.

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+1

| The_President 23 days ago | root | parent | prev | next [–] Proclaiming professional advice on the internet should compel you to bother using proper caps and punctuation. To your point - you are addressing the symptoms of bad understanding of CSS and it's relationship to the DOM. While tailwinds is a useful tool, it's not particularly special.

| danaw 23 days ago | root | parent | next [–] could you read what i wrote? if capitalizing words make me unprofessional, so be it :shrug:

| The_President 23 days ago | root | parent | next [–] It's evident that proofreading your own comment might be more effective if it were written more carefully from the start.Most people indent their code for legibility - if someone showed up to a code base and didn't do that, it could be offputting to anyone reading it.

| flossly 23 days ago | parent | prev | next [–] While I agree I do think there's some "aspiration of purity/correctness" in your approach that I've long let go of.I look at the royal mess that is HTML/CSS/JS as a necessary evil, required when we want to target browsers. To me it's "just the presentation layer".In my work I put a lot more emphasis on correctness in the db schema, or business logic in the backend.When it comes to the messy presentation layer I prefer to write a little as possible, while still ending up with somewhat maintainable code. And for this Tailwind fits the bill really well: LLMs write it very well, new devs understand it quick, and it's quite easy to read-back/adjust the code later.I 100% agree a Tailwind project is not the best way for a new dev to learn HTML/CSS. But then I prefer the new dev to focus on great db schemas, intuitive APIs, test-able biz logic, etc. Fiddling with the mess that's HTML/CSS is not the place where I consider human attention is best spent on (or where developers pick up skills to become much better developers).

| TonyAlicea10 23 days ago | root | parent | next [–] 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.

| flossly 23 days ago | root | parent | next [–] 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".

| embedding-shape 23 days ago | root | parent | next [–]

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 :)

| DANmode 22 days ago | root | parent | next [–] Notably, this is also how most businesses treat their sighted end-users…

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

| shimman 23 days ago | root | parent | next [–] It's a great way to make an easy $10-30k as a law firm too when you sue them. Especially when you have definitive statements like "we purposely don't care about a11y until we get sued for it."

| throwaway24274 23 days ago | root | parent | prev | next [–] It's not just blind people, but also people with reduced eyesight. As I'm getting older, I really appreciate good contrast and the possibility to zoom in without breaking the layout.

| 48terry 23 days ago | root | parent | next [–] People always forget they're one unlucky event from losing their sight, hearing, dexterity, or more. Hell, like you say, even aging's enough to do it. Accessibility suddenly becomes a lot more important when you're on the other side of the "not a priority" talk.

| extra88 23 days ago | root | parent | next [–] If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem. For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigger and/or a different font or weight).

| stefan_lec 23 days ago | root | parent | next [–] This is not true. Tailwind defaults to rem as the underlying length unit for almost everything. You have to go to extra effort in most cases to use px.

| extra88 22 days ago | root | parent | next [–] Note the word "if" at the beginning.

| reaperducer 23 days ago | root | parent | prev | next [–] if we get our first blind user I will gladly make some admends to make it more usable for them. Not good enough. You have to be accessible before it is needed in order to avoid legal liability.And how do you expect to get a blind user if they already cannot use your product?None of the doctors I build web sites for are currently blind. I know this because I talk to them regularly. But I still build the web sites for the future, when HR might hire a doctor or nurse or other person who is blind, or partially sighted, or has trouble with their muscles, or has difficulty distinguishing colors.Doing the right thing isn't that hard. Not doing it is just lazy.

| ncphillips 23 days ago | root | parent | next [–] We use tailwind and are capable of building accessible websites without any issue. People could make all the same mistakes with CSS for accessibility. It’s the not knowing how to make accessible content that leads to inaccessible content, not the tool you use to implement the styling.

| flossly 23 days ago | root | parent | prev | next [–] 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.

| 48terry 23 days ago | root | parent | next [–]

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?

| LtWorf 23 days ago | root | parent | next [–] A former coworker of mine opened a meeting saying "we are so good, we care about accessibility". I had been complaining for months and finally a customer had said "we won't buy your product unless it complies to the law".

| reaperducer 23 days ago | root | parent | prev | next [–] I find the "legal liability" claim hilarious You must have six million dollars laying around. Because that's the penalty Target paid for not having an accessible web site.

| _puk 23 days ago | root | parent | next [–] In 2008..That wasn't even a regulatory penalty, but a class action by the National Federation of the blind.https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...

| 0x3f 23 days ago | root | parent | prev | next [–] Sounds like you're kind of just talking your book though. Person who makes accessible sites suggests you need an accessible site. Blind people aren't the only ones who might need modifications. You could have an infinitely long list of adjustments for all kinds of disabilities, and tell me I'm lazy for not doing each of them. Why are blind people special?

| well_ackshually 23 days ago | root | parent | next [–] You are lazy for not doing accessibility adjustments, because accessibility isn't for blind users. It's for the deaf ones, the ones with poor eyesight, the ones with mental deficiencies, the ones with motor issues like Parkinson's, the ones browsing your site shitfaced at 4AM, and so on and so on.Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally makes your website less shit. You slapping an aria-label doesn't fix things.

| 0x3f 23 days ago | root | parent | next [–] 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.

| esseph 23 days ago | root | parent | next [–] 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.

| 0x3f 23 days ago | root | parent | next [–] 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.

| hparadiz 23 days ago | root | parent | next [–] This is just admitting that your product is small and unimportant.

| 0x3f 23 days ago | root | parent | next [–] Hardly, I can trivially find Fortune 500 websites without accessibility.

| 0x3f 23 days ago | root | parent | next [–] Ok well enjoy your thought-terminating cliches in the meantime

| 0x3f 23 days ago | root | parent | next [–] You're just expressing a normative view here, it's not very interesting or informationally-dense. You care about accessibility more than I do. That doesn't make not doing it 'crap'.

Maybe I have even higher RoI/EV stuff to be doing.I mean, to readers of these comments, I think it's right there for you: 0x3f will take "higher ROI" over "accommodate and support disabled people".

| 0x3f 23 days ago | root | parent | next [–] Yeah, thats explicitly what I'm saying so I'm not sure it needs repeating. That has very little to do with it being lazy though, is the point.We were already implicitly discussing RoI when we were talking about 'legal consequences' above. This is how people decide between alternatives, generally.

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.

| TonyAlicea10 23 days ago | root | parent | prev | next [–] I mentioned blind but there’s lots of others. Folks sitting a desk whose eyesight are getting worse and are scared to say so for fear of losing their job, for example. This happens.Side note: if you aren’t deliberately choosing semantic elements and instead dropping aria attributes onto a bunch of divs this is an anti-pattern.

| The_President 23 days ago | root | parent | prev | next [–] Knowing the DOM structure is properly engineered is the gateway to an entirely compliant end product out the gate. Leaves pros looking for the "difficultly level" on SEMRush after maxing it out.

| jbreckmckye 23 days ago | root | parent | prev | next [–] 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 someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.

| extra88 23 days ago | root | parent | next [–] 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.

| jbreckmckye 23 days ago | root | parent | next [–] 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).

| extra88 23 days ago | root | parent | next [–] Sure. I don't know where you're claiming that misinformation is coming from, it doesn't have anything to do with what I wrote. I was referring to CSS properties that affect the accessibility tree.

| jbreckmckye 23 days ago | root | parent | next [–] The person I am replying to1. Argues that Tailwind requires div-itis2. And that divs affect the accessibility tree

| TonyAlicea10 23 days ago | root | parent | prev | next [–] 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.

| gf000 23 days ago | root | parent | next [–]

let me add a div so I have a place for my CSS classAs opposed to what exactly? HTML doesn't let you lay out stuff properly without at least some structural divs that have no meaning.If we have the proper aria properties for example, why does it really matter if I have extra divs (which is, again, irrespective of tailwind)

| TonyAlicea10 23 days ago | root | parent | next [–] I can do a lot of layout without divs. Adding aria to divs is an anti-pattern and likely a worse experience than semantic elements.You might need some extra divs for layout sure. But I guarantee less than most people are using if they markup their content first.Remember divs mean nothing. So the opening example on the Tailwind website is the accessible equivalent of “blah blah blah”.

| stefan_lec 23 days ago | root | parent | prev | next [–] This is nonsense, you can stick classes on semantic HTML elements just as easily as on a div.And screen readers can handle elements nested inside a grouping div just fine, that’s how div’s are supposed to be used. The accessibility issues with div’s are when people repurpose them to take the place of existing semantic elements, because doing so requires handling a bunch of aria roles and attributes manually, and something invariably gets missed.

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

| gjsman-1000 23 days ago | root | parent | prev | next [–] 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.

| hidelooktropic 23 days ago | root | parent | next [–] I guarantee you no one is working on this.

| DANmode 22 days ago | root | parent | next [–] 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.

| DANmode 22 days ago | root | parent | next [–] Have you seen the frontend of most apps? =]The conversations here regarding UX? (Acting like it’s black magic, not basic empathy?)The exact same disconnection exists between dev and abled users.

| vehemenz 23 days ago | parent | prev | next [–] A few counterpoints:Treating markup and styles separately is great, in principle, but you'll always need additional markup for certain things. We knew this going back to the early 2000s.There is nothing about Tailwind itself that forces you to use divs and spans instead of the appropriate HTML tag.Documents and interfaces are different. Tailwind makes a lot more sense for interfaces. You can use Tailwind for the interface and scoped HTML selectors for other content.Tailwind is around 4x faster and has practically no overhead compared to writing a complex CSS codebase. Whatever you think of it, this is always a benefit in its corner.

| TonyAlicea10 23 days ago | root | parent | next [–] Folks in this thread keep conflating “forces to” and “ergonomically encourages”.If a power tool is poorly designed it may not force me to hurt myself but if it makes it easier that’s a problem.

| fluffybucktsnek 21 days ago | root | parent | next [–] TBF, Tailwind is more about optimizing CSS sizes via the utility classes approach IIRC.

| hahn-kev 23 days ago | root | parent | prev | next [–] I always feel like the distinction between interference and document is missing in these types of discussions. Often times they're as different as native vs web dev and if you don't realize that then you're arguing about totally different things and nothing will make sense.

| spiderfarmer 23 days ago | root | parent | prev | next [–] As someone who wrote CSS for 20 years and who was against using Tailwind because of “principles” I must say that Tailwind is just awesome. Every minute spent trying to make sense of the structure past you or your colleagues came up with is a minute that could be spent on something more important.Every time someone says that Tailwind sucks, it’s like hearing the old me speak.

| ncphillips 23 days ago | root | parent | next [–] Same here. It’s super weird take to me now. Maybe if you’re just writing plain HTML and CSS tailwind would be worse, but assuming there’s a component system you’re going to be just fine. The cascade of CSS is such a foot gun. Localized styles work great and tailwind abstracts away hardcoded values with relative ones

| paulhebert 23 days ago | root | parent | next [–] I prefer writing plain CSS over TailwindBut I get component-scoped CSS (via Vue) and use custom props to abstract away hardcoded valuesTailwind isn’t the only option for those features

| alwillis 23 days ago | parent | prev | next [–] It's unfortunate Inverted Triangle CSS (ITCSS) isn't more popular. Instead of resisting the cascade, it embraces it and makes it work for the developer.The summary: write your CSS in specificity order [1]:

/scss/ ├── 1-settings. <- global settings ├── 2-design-tokens <- fonts, colors, spacing, etc. ├── 3-tools <- Sass mixing, CSS functions, etc. ├── 4-generic <- reset, box sizing, normalize, etc. ├── 5-elements <- basic styles: headlines, buttons, links ├── 6-skeleton <- layout grids, etc. ├── 7-components <- cards, carousels, etc. ├── 8-utilities <- utility and helper classes ├── _shame.scss <- hacks to be fixed later └── main.scss

ITCSS basically does away with specificity wars in a CSS codebase. Usually the only place !important is the utility layer.[1]: https://matthiasott.com/notes/how-i-structure-my-css

| funksta 23 days ago | root | parent | next [–] Aren't Cascade Layers [1] a more reliable, native solution to the specificity problem? In 2026, why not lean on them instead of source order?[1] https://developer.mozilla.org/en-US/docs/Learn_web_developme...

| alwillis 21 days ago | root | parent | next [–]

Aren't Cascade Layers [1] a more reliable, native solutionLike many new-ish CSS features, adoption is low; around 4-5% from a crawl of 17 million sites [1]. It's been available in all major browsers since 2022.I'm generally addressing developers who are never going to use any (or very little) modern CSS [2]. There was a thread on HN where some participants complained about "all these newfangled CSS features". Several didn't see the need to learn CSS Grid, even though it's been available for nearly 10 years. (Aside: I really disliked the floats/tables-for-layouts era, with the requisite IE hacks.)There are lots of developers who don't see a need to use features they weren't using in the late '90s or early 2000s. For a lot of them, they'd rather use the devil they know.There’s a huge gap between web developers who speak at web conferences, appear on CSS-themed podcasts, and who are members of standards bodies vs the 9-5 developer that works for some insurance company or school, who's not a CSS enthusiast or hobbyist. Using ITCSS would be awesome them.Finally, there's nothing unreliable or non-native about ITCSS; it's just CSS where the layers are in specificity order. It doesn't get any more native than that.[1]: https://almanac.httparchive.org/en/2022/css[2]: https://modern-css.com

| SquareWheel 23 days ago | root | parent | prev | next [–] Yep, they solve the same problem. I built my blog on Harry Roberts' ITCSS paradigm some ten years ago, and found it extremely easy to migrate to cascade layers. They're an underutilized solution to addressing growing specificity.They're admittedly less useful if you're already using component-based design. That's closer to something like BEM in hyper-targeting each element.

| infamia 23 days ago | root | parent | prev | next [–] This is brilliant, I was not aware of ITCSS. Thank you for sharing! The link you shared fits my brain a lot better than pure BEM/CUBE, which works but always felt weird and uncertain to my style. Sprinkling a bit of BEM on top of ITCSS feels just right. shame.scss is the snarky cherry on top. Thanks again, you have enlightened at least on person today! :)

| alwillis 21 days ago | root | parent | next [–] In hindsight, ITCSS is so obvious. Makes you wonder why so many people think CSS is difficult.

| mhitza 23 days ago | parent | prev | next [–] 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 then add css classes on top.

| xigoi 23 days ago | root | parent | next [–]

If I look at their component library, they also do the work of including aria attributes for youUsing ARIA attributes instead of semantic elements is bad for accessibility.

| rhdunn 23 days ago | root | parent | next [–] 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/

| extra88 23 days ago | root | parent | next [–] 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/...

| stefan_lec 23 days ago | root | parent | next [–] Details/summary had quirky/inconsistent handling by screen readers for quite a while after it reached full browser adoption, unfortunately. Not even sure if they’ve fixed it here in 2026, honestly.https://www.scottohara.me/blog/2022/09/12/details-summary.ht...While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t actually very accessible (like native form validation), or where you just can’t avoid it (using aria-disabled instead of disabled for submit buttons, setting aria-pressed for toggle switches, setting aria-expanded for buttons that trigger modals, situations where you need aria-hidden/sr-only, etc).Though once popovers and the invoker command api hit baseline widely available, we’ll be able to drop some of that.

| extra88 22 days ago | root | parent | next [–] I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that).Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.

| fluffybucktsnek 21 days ago | root | parent | next [–] It should polyfills are basically a no-go for no-JS sites.

| mcv 23 days ago | parent | prev | next [–] I agree. I don't really like Tailwind, nor similar CSS frameworks. The whole idea was to separate styling from HTML, and Tailwind is putting it back into HTML through the backdoor. It's just a way to do styling from your HTML without having to touch the CSS, by inserting styling info in your HTML. That's exactly what we were trying to move away from.

| aleksiy123 23 days ago | root | parent | next [–] I think this assertion is where most of the conflict comes from.There is a fair amount of people that disagree with the premise that it should be separated in that way (Including me).I personally like this essay by the author of htmx on the topichttps://htmx.org/essays/locality-of-behaviour/Also just better composition imo.Practically I think this means components of scoped css, html, js.People never seem to have the same complaint about mixing or separating app code and sql in the same way?

| wwweston 22 days ago | root | parent | next [–]

it is important to make the distinction between inlining the implementation of some behaviour and inlining the invocation (or declaration) of some behaviourtailwind’s biggest problem is that it doesn’t make this distinction well.In a sense this is a strength because it probably matches the amount of effort most devs/orgs who don’t focus here are willing to put in to the problem; this worse-is-better solution is functional enough especially in settings where component separation has already been adopted. Along with some decent baseline design tokens, it’s enough for people who don’t want to care more, especially if they don’t ever particularly see the consequences of hyperlocalizing implementation.If your project has someone whose job it is to think through design systems and how they’re expressed via CSS, you can do better. If you don’t, you can do worse.And personally, I’ve seen a LOT of discussion about separating SQL and app code. There’s a similar tension. Wrapping queries in function calls often means fewer duplicated queries (often painfully verbose) and opportunities for dumb security mistakes, but reduces the expressive variation the raw query language provides, and many systems and devs behind them end up pursuing balance between the two… or outsourcing the decision to an ORM or other data access layer whose tradeoffs also probably have shortcomings but at least they get to worse-is-better stop thinking about it except at particular pain points.

| timr 23 days ago | root | parent | prev | next [–] 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.

| aleksiy123 23 days ago | root | parent | next [–] 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 wrapper functions is less understandable than inlining for a single statement, or global mutations are harder to trace then local, and that sometimes its easier to inline a single sql statement then split it out into a different file just because its 2 different languages.Also, to be clear its possible to write CSS that exhibits less or more LoB. The file thing is more that I don't think HTML, CSS, JS "must" be written as separate files which is what the prevailing best practice used to be, justified as SoC. I just think splitting along the scope/behaviour lines rather than file type is more understandable.

| mcv 22 days ago | root | parent | next [–]

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

Its not so much about same file, as reducing distance to understanding, whether visually or by some sort of easily traceable path.The metaphor remains valid. You can do this all the way down the abstraction stack, back to functions.

| aleksiy123 23 days ago | root | parent | next [–] 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 applied and a single definition.With css that’s not necessarily true. There’s a bunch of different rules that may or may not apply.

| skydhash 23 days ago | root | parent | next [–]

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

| aleksiy123 23 days ago | root | parent | next [–] 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.

| skydhash 23 days ago | root | parent | next [–]

that’s exactly the part that is anti locality of behaviour.It is not. Because it fits the concept of "web pages" as documents and forms (which most web apps are, even if they're trying to pass as desktop applications.> 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.And you're very welcome to do what you want. But there's no need to bash cascading as it's a good solution for web pages.

| aleksiy123 23 days ago | root | parent | next [–] End users and even other programs/extensions can load rules to alter your styles. I think thats about as opposite of locality of behaviour as it gets. (no judgment on customization on being good/bad).With the rest I don't really strongly disagree. I think its just a question of complexity. For simple things its fine, but for complex apps with teams of people :shrug:

| isleyaardvark 23 days ago | root | parent | prev | next [–] This is the misconception that has caused so many problems over the years, problems that the Tailwind approach solves.There was never any separation of concerns within the HTML code, the class="" property is in the HTML and that is the styling info. Devs took the idea of separation of concerns of content, presentation, and behavior as separation of technologies: HTML, CSS, and JS, which is not the same. So they tended to think, "oh no, with classes I've got presentation code in my content (HTML) and I need to put it all in my CSS." But HTML is not content, it contains content. And all the separation of concerns is done with how the HTML is written.For example take this code

Bleh!

That has separation of concerns. The content is Bleh!, the content semantics are h2, the styling is all in the class, and the data-index is used only as a hook for javascript. Violating separation of concerns would involve using those properties for multiple concerns. Particularly the h2 class="h2" part. It looks a bit silly at first glance, particularly if you have a bunch of

and

's in the codebase. But that has proper separation of concerns, and I have many times run into cases where I want an

or

, and in those cases, because I have proper separation of concerns, all I have to do is change the actual content layer to whatever is appropriate without worrying about the presentation layer changing because someone put an h2 { font-size: 1.6rem; } in the css.The only difference between the old-school approach and the Tailwind approach is the API between the HTML file and the CSS. The old-school approach tends toward terrible abstractions because devs are trying to code the presentation for an element while feeling they need to describe the presentation in as few terms as possible, because they think that amount of characters is separation of content. Tailwind takes the approach that the class property is the presentation layer and you can use your words to describe it clearly.I'd add that what I've seen with the older approach almost always leads to much more co-mingling of concerns (maybe because those devs get so focused on "all style should be in the CSS"). That's when I see things like ul > li { padding: 1rem; }, which is fine until you decide to change it to an ol. Or even .foo > .bar { ... }, which is dependent on the structure of the content.Yes, Tailwind is ugly as sin but it's effective.

| wwweston 22 days ago | root | parent | next [–] HTML is content because it inflects content with structure and meaning. It may be fair to say it carries less of the semantic weight than the language and other media it marks up, but it’s content at least to the extent that punctuation is, and perhaps more.I don’t know anyone whose concerns with “presentation” in markup included the presence of classes — the dominant understanding among people I’ve known who care about this is that classes are semantic in the markup with names chosen for that purpose and they have presentation attached in stylesheets.Tailwind gives up on that separation. There can be some worse-is-better benefits to that, especially for teams that don’t have anyone whose role is to care about this. But the “ugly as sin” is a signal about the shortcomings in the tradeoff.

the class="" property is in the HTML and that is the styling infoThe class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

| isleyaardvark 22 days ago | root | parent | next [–] Yes, and that’s what it’s used for now due to the ad hoc development of HTML and CSS.

| cxr 22 days ago | root | parent | next [–] What?

| isleyaardvark 23 days ago | root | parent | prev | next [–] I think I can make what I wrote above a little clearer by putting it this way. When the class property gets really long, that's not a violation of separation of concerns, because you are not really co-mingling content with presentation. HTML is not content but contains content.

| reaperducer 23 days ago | parent | prev | next [–] HTML is marking up the meaning of the document. You should start there. Then style with CSS. This is precisely how I do it.Code that generates HTML. Once I can see all the content on the screen in some kind of Netscape Navigator 1.0 nightmare, then I go back and add styles to make it look pretty.It's not hard. It just requires thought and planning.(The best planning tool I've found is a pencil and grid paper, not the web design SaaS-of-the-moment. However, it's surprisingly hard to find good pencil sharpeners these days.)

| uxcolumbo 23 days ago | parent | prev | next [–] What's a good source to learn how to develop like this - to create HTML / CSS structure that's accessible?EDIT: ignore. I can see you have some links in your profile. Will check it out.

| therealpygon 23 days ago | parent | prev | next [–] It does make that easier for people to choose to do, but I would argue that it shouldn’t be held against tailwind that people do this. Also, sorry, but I’m doubtful that when using CSS that no markup would be changed to better accommodate the final layout…just like tailwind?If the first tool in your tool chest is to change the markup, then it doesn’t matter which method of styling you apply. If your first goal is clean markup and accessibility…then It doesn’t matter which method of styling you apply.

| gofreddygo 23 days ago | parent | prev | next [–] I agree with the criticism of tailwind. IMO any good criticism warrants at least an opinion on what should be done instead or some corrective or remedial patterns.there is a reason why tailwind got as popular as it is today. And it only highlights the gaps in either what HTML and CSS provide for the task at hand or the difficulty in that approach. This must not be lost in any criticism.another observation is none of technical user interface decisions or discussion emphasis on the tree data structure that is inherent to every major user interface rendering mechanism relevant today. there are inherent benefits and drawbacks of it being a tree structure that neither of the developers nor the framework leverage. when thought of as a tree, it benefits from adding certain constraints and naming conventions that allow more artistic expression using just HTML and CSS that I have not seen tailwind or any other framework encourage

| mb2100 22 days ago | parent | prev | next [–] Yeah, while you certainly can write semantic HTML with Tailwind, it absolutely doesn't encourage it. It's funny how Tailwind is conceptually going back to inline styles.But sure, if you have

, <header> and </header>