I think OP is pointing to the irony of using an increasingly verbose and overly complex wrapper API that makes it utterly painful to maintain styles "just" to avoid learning css, which is regarded by many developers as confusing or hard to learn, but is actually much more accessible, legible and maintainable than what Tailwind had become by now.
I might be reading a lot into this remark and mostly relying my own opinions here though.
But throughout the years I've been seeing how CSS is universally met with insane prejudice and expectation of it being "too complicated" or painful to learn, and Tailwind being praised as the solution while actually being much more verbose and obfuscated, and time after time leading to irrecoverable tech debt, utterly illegible markup, and complete dead ends whenever style needs any kind of refactoring.
Now that CSS is maturing and getting tons and tons of new features, Tailwind lags behind and keeps introducing more weird workarounds and hacks to be able to support all of it. The line in OPs comment is an example of it literally coming down to writing mutilated CSS selector statements directly to html attributes just to be able to do some of the stuff `:has()` enables, and creating horribly illegible markup and non-reusable styles in the process ...
Imho the original issue leading to "stylesheets are a pain" was never really CSS itself (at least since module 4 & custom props), but rather the top level management of tokens in a design system to not have to memorize colors and sizes etc -- Tailwind is simply collaterally fixing the right problem with the worst approach thinkable, but keeps being hailed as a holy grail by people who lack understanding of this.
Perhaps the point of Tailwind isn't to obviate the need to learn CSS. Which seems obviously true to me, given that if you don't know CSS you can't really use Tailwind very effectively.
There's definitely a 0.1% long tail that's tricky with Tailwind (like this), but 99.9% of app styling is so ludicrously fast in Tailwind as compared to writing raw CSS.
It definitely isn't, my point is that it seems to be largely is misunderstood as this being it's main purpose.
Tailwind is unquestionably accelerating drafting up a custom UI, and also makes this much more approachable for webdevs unaccustomed to CSS
The pitfall of declaring all your styles as strings of shorthands in html atts also might never hit you if your UI doesn't get too complex and/or never needs refactoring - but it hits hard if your codebase had grown to a certain scale over the years, and you suddenly need to change or refactor larger parts of the UI
I disagree with the main motivations and benefit. For me it’s always been about being able to handle hover states etc without having to leave the local context where I’m working. I don’t think anyone can really write tailwind without understanding css.
Adobe Brackets had an interesting solution to the context switching problem. There was a keybind, I think CTRL+E, that would let you edit all the styles that apply to the current element in a kind of inline sub-editor. It was quite neat and I haven't seen it done in any other editor.
You didn't have to leave the local context if you use very local stylesheets. Scoped CSS like shadow DOM, plus CSS text right with your component, helps a lot with this.
Style attribute lacks a selector (“color:red” vs. “.comp {color:red}”), forbidding the most useful use case. Shadow dom is an inspection nightmare used only by a few progressive web purists. Style.css is an untyped incoherent spaghetti. There’s no really good place for an element style in current implementation.
op is not talking about style atts, but referring to nesting inline `<style> @scope { ... }</style>` to declare vanilla css in the scope & context of specific DOM nodes
if the styles only concern the context you work on, this could easily be done with vanilla scoped inline styles
If those declarations are relevant to multiple components within your codebase, then you'll still need to leave the context when your styles are inlined and therefore declared in multiple places
No. That’s the point of tailwind. You can include things like hover states. Inline css hits a roadblock there and you’re forced to go out to a style tag. Then you have to start naming things. Then you risk conflicts.
CSS took 20 years to begrudgingly incorporate the most useful features of SASS, and these are still not wide spread or (like nesting) have become available barely a year ago.
CSS is verbose, repetitive, error-prone, and requires insane workarounds to keep it manageable.
There's a reason why SASS has been nearly a de-facto industry standard, and why abominations like BEM exist.
SASS and LESS have their place, but they are tooling, not replacements
The time it took for CSS to progress like this although is on Browser vendors, not on the language - lots of recent features that seem utterly late to the game have existed for years and years, but had to be deemed "unsafe" to use because of Safari, Firefox and other browsers that lag far behind the standard.
And honestly, the critique you throw at CSS is all the more true for Tailwind actually, and imho only stands the test for _badly written_ code, which holds true for any language in any domain.
And regarding why BEM exists: it's just a flavour of naming convention for your "API", nowhere mandated by CSS itself. Its main purpose is to optimise paint performance and keeping your component naming lean and transparent. You may very well simply write expressive and specific queries instead of defining naming conventions for your components.
But I'm unsure if we talk about the same things in the end, cause none of those points get any better with Tailwind, rather the opposite.
> because of Safari, Firefox and other browsers that lag far behind the standard.
I could've guessed there would be a blame game.
No, neither Safari nor Firefox lag in web standards. Moreover, it was Firefox (IIRC) which figured out how to do nesting safely.
However, even beyond nesting there multiple other things that lagged in browsers. CSS Scope was completely derailed by Chrome's push for Web Components, and had to be solved by other tools.
Nesting, mixins and a lot of other tools were long seen by all browser vendors as "unnecessary and better solved by tools". So yes, SASS isn't a replacement but there are reasons why it existed and was a nearly de-facto standard in tooling for so long. And that reason isn't "CSS is so great".
> And regarding why BEM exists: it's just a flavour of naming convention for your "API", nowhere mandated by CSS itself. Its main purpose is to optimise paint performance
No, it's main purpose is to try and close the gap in CSS: CSS is/was absolutely horrendously unsuitable for any type of componentized code. And BEM was an attempt to solve that at the process/naming level.
No, BEM isn't mandated by CSS. However, it exists because CSS had literally no tools to support the use cases BEM was aimed at.
> But I'm unsure if we talk about the same things in the end, cause none of those points get any better with Tailwind
I didn't even talk about Tailwind. I was directly addressing your claims about CSS.
I might be reading a lot into this remark and mostly relying my own opinions here though.
But throughout the years I've been seeing how CSS is universally met with insane prejudice and expectation of it being "too complicated" or painful to learn, and Tailwind being praised as the solution while actually being much more verbose and obfuscated, and time after time leading to irrecoverable tech debt, utterly illegible markup, and complete dead ends whenever style needs any kind of refactoring.
Now that CSS is maturing and getting tons and tons of new features, Tailwind lags behind and keeps introducing more weird workarounds and hacks to be able to support all of it. The line in OPs comment is an example of it literally coming down to writing mutilated CSS selector statements directly to html attributes just to be able to do some of the stuff `:has()` enables, and creating horribly illegible markup and non-reusable styles in the process ...
Imho the original issue leading to "stylesheets are a pain" was never really CSS itself (at least since module 4 & custom props), but rather the top level management of tokens in a design system to not have to memorize colors and sizes etc -- Tailwind is simply collaterally fixing the right problem with the worst approach thinkable, but keeps being hailed as a holy grail by people who lack understanding of this.