341–350 of 435 posts
That said, it is a good post putting all those things into one post and give a sane baseline for people who are new to this, or don't know the web's basics well.
CSS Modules are a simpler solution to cascading problems. They create unique class names, so your classes don't clash [1]. And they don't have the two main downsides of TW, which are readability [2] and tooling. Tooling for debugging and experimenting interactively with Chrome and FireFox DevTools. [1] https://x.com/efortis/status/1888304658080256099 [2] https://github.com/ericfortis/tailwind-eye
One thing that has always struck me about Tailwind is that practically every argument its proponents use more or less boils down to “I never learnt CSS beyond a junior level” . It’s super common to hear Tailwind advocates say things like “Without Tailwind, we would just have one big disorganised CSS file that always grows uncontrollably and ends up with loads of obsolete stuff in it and !important everywhere! Tailwin…
It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself). It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might b…
I've worked with CSS since 2001. Understood the CSS rendering engine in Mozilla like the matrix and written an absolute ton of cascading CSS using various methods and frameworks. All my stuff is now tailwind and it's pure bliss.
Earlier quoted context omitted.
Modules make the global thing less of a concern these days.
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.
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…
> 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 selectors In my opinion, it's the opposit…
Classes 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.
Earlier quoted context omitted.
It is really fun that the navbar has unaligned elements. (Docs is lower)
we were focusing on Mobile and Desktop versions, are you somewhere in between? to be tracked here: https://github.com/anyblades/blades.ninja/issues/7
Earlier quoted context omitted.
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).
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.
1. Argues that Tailwind requires div-itis
2. And that divs affect the accessibility tree
Earlier quoted context omitted.
> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hu…
I for one do not understand what is so difficult about making a team internal decision about how some "component" (here in quotes, as I am actually thinking of an HTML subtree with specific purpose somewhere on an HTML page) is going to be named, and then give it that name as CSS class. Are people never talking with each other? Are people unable to grep a code base, before making up a new name? And how many similar b…
Say you have a .button class for clickable button elements. One day a junior engineer realises they need two of them next to each other, while one is more important. Predictably, as they don't want to bother one of the seniors with this, they are going to introduce a .secondary variant. A few days later, someone else gets tasked with introducing a variant prop for , so the upsell banner can be styled differently easily. "Oh!", they think, "Neat! there's a secondary class that sets all the same props I need!"—and just like that, coupling was introduced.
Sure, this is a contrived example. The junior could have scoped the class to buttons; or added an explanatory comment; or written a note to the team; or asked a senior; someone could have seen it in code review; or a heap of other mitigations. But all of these happen to fail sometimes, and compound over time. This isn't even really about CSS, but entropy at the end.
So to me, this is the benefit Tailwind brings to the table: By providing a styling language that doesn't require making up rules as you go, that scales to arbitrary project sizes, and most importantly doesn't need additional communication, you get optimized, side-effect free CSS that you will immediately be productive in, even as a new joiner or when you return after a long time.
Earlier quoted context omitted.
> Tailwind instead pushes the dev into a CSS-first approach. You think about the Tailwind classes you want, and then throw yet-another-div into the DOM just to have an element to hang your classes on. I wholeheartedly disagree. That mindset is not caused by Tailwind, but by being ignorant. You can perfectly create an HTML document with semantic meaning and the add Tailwind just as any other CSS framework or pure CSS…
The HTML spec says divs are the element of last resort. This issue isn’t that they’re bad. The issue is they are reached for far too quickly. Also if you think massive numbers of nested divs don’t have a performance impact in the DOM when reusable components are nested (because “styling”), you’re wrong.