The spec authors should be looking at the popularity of Tailwind and be thinking of how to enhance the style attribute. Then Tailwind really could mostly be a bunch of CSS variables and inline styles.
Tailwind depends on @apply in PostCSS to function, something that was never officially proposed for CSS, but has been killed by its author and we know for sure CSS won't do, for the reasons the author of the original @apply idea lists here: https://www.xanthir.com/b4o00
So we have known all along that this will never happen. It was rejected for some very good reasons before Tailwind began.
The only time I can imagine coupling content and styling together is if you have mostly non-repetitive elements in the content (rare, I think, maybe some very "designed" landing page, or whatnot), or you have other ways to repeat the elements without writing the styles out each time for each element. (And at that point you've just moved the problem of having to invent names for CSS classes to having to invent names for bunch of "components" and their properties)
This is achievable in a much nicer way with SFC frameworks like Vue and Svelte where you also get scoped styles and other benefits. One of the reasons Tailwind is so popular is that so few developers know anything other than React.
Of course it's just class names, what I mean is that if fewer people used React and more used Svelte/Vue they would feel less need for things like Tailwind or CSS-in-JS.
My argument is that React is actively bad for writing HTML/CSS, and therefore people came up with clunky solutions to get around those limitations. Certainly Tailwind is more than just a solution for React, but a large part of its popularity is due to it.
> they would feel less need for things like Tailwind or CSS-in-JS.
Why do people keep mentioning Tailwind and CSS-in-JS in the same sentence?
And no, Tailwind would still have its place even if Svelte appeared first because instead of writing the same styles everywhere you'd still want to extract them into a file, and have sensible defaults for them.
> Why do people keep mentioning Tailwind and CSS-in-JS in the same sentence?
Because one of the biggest arguments for each is scoping styles to a component instead of the default global cascade.
> And no, Tailwind would still have its place even if Svelte appeared first because instead of writing the same styles everywhere you'd still want to extract them into a file, and have sensible defaults for them.
Writing same styles everywhere? I'm not sure I understand what you mean, that isn't related to Tailwind or frameworks. Sensible defaults are just design system tokens, those are usable in way more styling approaches than just Tailwind.
I'm not saying Tailwind wouldn't exist, I'm saying it wouldn't be as wildly popular as it is now. React's lack of CSS features has encouraged a generation of frontend devs to simply not learn CSS fully. Sure you need to know some CSS to use Tailwind, but in many cases people just copy-paste Tailwind templates from elsewhere (another benefit of Tailwind) and don't actually understand the styling. I see Tailwind classes that do nothing in the wild all the time.
> Because one of the biggest arguments for each is scoping styles to a component instead of the default global cascade.
Escaping the global cascade has been on everyone's mind since forever. BEM, one of the lost popular ways to try and scope CSS to components, was invented in 2006: https://en.bem.info/methodology/history/
