If it sounds like I'm a sore winner, that's because I am. But OK. Here we are. Finally.
Tailwind 4 now comes with a theming system based on—wait for it, wait for it—CSS.
[#]CSS. What a concept! 😅
Yes, the ships have turned around in #WebDev. React 19 can now play in a world where not all of your components are built with React, and Tailwind 4 can now play in a world where not all of your #HTML markup is riddled with utility classes:
https://thathtml.blog/2024/12/tailwind-4-a-mea-culpa-moment/
=> More informations about this toot | More toots from vanillaweb@intuitivefuture.com
@vanillaweb my understanding of v4 is the opposite. Previous versions are a JS library for managing CSS, with postcss extensions as a detractor-appealing anti-pattern. v4 is a full-blown CSS framework, where using framework-specific CSS is the idiom.
=> More informations about this toot | More toots from olets@hachyderm.io
@olets uh, that's what I said: migrating from a JS-based configuration to a CSS-based one with real CSS variables. How is that the opposite?
=> More informations about this toot | More toots from vanillaweb@intuitivefuture.com
@vanillaweb will try to clarify. To me, v4's going all in on CSS vars is a nice change but incidental. For me the headline is the change from a layer for interacting with vanilla CSS where if you choose to write CSS the idiom is to write vanilla, to a layer in front of CSS where you are expected to write framework-specific CSS and preferably to only work within the framework (which happens to be in CSS). That's a significant realignment towards the idiomatic and esoteric
=> More informations about this toot | More toots from olets@hachyderm.io
@vanillaweb for years I've taken the position that the framework aspect of Tailwind isn't the aspect to look at. It's not the aspect that hooked or interests the CSS-knowledgable Tailwind fans I know (myself included). Haven't tried v4 on anything of size, but it seems like it flips that, fully deemphasizing "to use TW you need to know CSS", leaving instead the "learn TW so you don't have to learn CSS" detractors have thought it was all along
=> More informations about this toot | More toots from olets@hachyderm.io
@vanillaweb so was surprised to see you applauding v4 while the conversation I've been having is "with v4 does TW become the thing which the anti-TW arguments until now have imo mischaracterized TW as? Will I have to start steering people away from TW, so that they learn CSS not just Tailwind?" Was interested reading your take, and am interested to see how it shakes out
=> More informations about this toot | More toots from olets@hachyderm.io
@olets Hmm, you're going to have to present a concrete example of what you're talking about. The problem before was that the configuration of all the theme design tokens (whether default or customized) was locked inside a JS file and the output bundle hardcoded all of those design tokens.
Now you can leverage those tokens in fully vanilla standard CSS files. They don't need to include anything framework-specific other than leveraging the theme variables: var(--color-blue-800) and so forth.
=> More informations about this toot | More toots from vanillaweb@intuitivefuture.com
@vanillaweb ah maybe we are just talking about different things. I'm talking about TW used as the docs expect; I thought your article's example of using TW values separate from using TW as the docs expect was being used as a springboard to comment on the nature of TW-as-the-docs-expect. But sounds like you aren't springboarding, but specifically talking about writing CSS that stays in sync with TW classes. Not something I've thought about doing, makes sense v4 would be a welcome change
=> More informations about this toot | More toots from olets@hachyderm.io
@olets ah yeah. glad that's cleared up now! 😊
=> More informations about this toot | More toots from vanillaweb@intuitivefuture.com This content has been proxied by September (ba2dc).Proxy Information
text/gemini