Tailwind CSS for ProcessWire Developers

[wbmnfktr]

Your grid area solution looks nice and clean!

While for the moment I use the plugin Grid Areas for TailwindCSS I might switch to your solution. There seems way less overhead with it.

[kongondo]

Tailwind Connect 2023: Recap of our first in-person event

https://tailwindcss.com/blog/2023-07-18-tailwind-connect-2023-recap

 

[flydev]

To users of TailwindCSS / Windy, I think you will want to use UnoCSS.

@MarkE just see your thread about your page builder, to avoid workarounds or hacks, you don't want to use interpolated or concatened strings. 

<div class="<?= $error ? 'text-red-600' : 'text-green-600' ?>"></div>

Do not pay to much attention to this comment, it's just for the science.

[bernhard]

Just found https://preline.co/docs/index.html today and I'm quite impressed! It looks like a more modern UIkit 🙂 @Jonathan Lahijani did you find time to try it since 2022 and have some experiences to share with us?

[Jonathan Lahijani]

@bernhard Within the Tailwind ecosystem, my goal was to find the "framework" that had the best JavaScript components (the typical things like accordions, tabs, etc.).

I started with Tailwind UI but that was geared for headless, however behind the scenes in their demos they had a hidden Alpine.js based solution.  That was hacky but I used it for a little bit.

Then Alpine.js itself had their premium components and since the two pair well, I went with that for a while but it didn't feel right in the same way that UIkit does.

Then I found Preline and played with that for a while, but a couple years ago it was good but not as good as Flowbite.  So I stuck with Flowbite for the last 2 years.

A couple months ago I re-visited Preline and they've made some incredible progress, so much so that I feel it's "ahead" of Flowbite.

Then a month or two ago, the folks at Tailwind finally released non-headless / vanilla JS components officially for Tailwind UI, which I haven't experimented with yet but I'll probably switch to that if it makes sense (which I'm sure it will):
https://tailwindcss.com/blog/vanilla-js-support-for-tailwind-plus

Also, I've been thinking about eventually switching back to vanilla CSS at some point because of how much progress it's made in the last 15 years.  I stopped writing vanilla CSS when Bootstrap 2 came out and every since then I've gone from one framework to another (Bootstrap 2 -> Foundation -> Bootstrap 3 -> Uikit2 -> Uikit3 -> Tailwind).

I love UIkit but I feel it's antiquated now and not taking advantage of all the new cool features of CSS.  I also came to not like being softly "jailed" in their way of doing things.  Also I like the idea of not using a build-step so vanilla CSS is probably what I'll settle on when I'm ready.

[bernhard]

@Jonathan Lahijani thank you very much! A lot of what you wrote resonates with me. Did you also try/consider daisyui? The have 35k stars on Github, a MIT license and so far I didn't find anything that I would miss coming from UIkit.

[Jonathan Lahijani]

I looked at DaisyUI but it relies on @apply under the hood which the creator of Tailwind said he wish he could uninvent so that didn't sit well with me.

[bernhard]

Interesting! As I didn't know what you mean exactly I asked perplexity:

Quote

Adam Wathan, the creator of Tailwind CSS, has publicly stated his regrets about adding the @apply directive to Tailwind. He has mentioned on Twitter that @apply "basically only exists to trick people who are put off by long lists of classes into trying the framework," and he recommends against using it in most cases. He has also said that @apply is the feature that causes the most issues for the Tailwind team and that they spend the most time debugging it.

The main criticisms from Adam and others around @apply are:

• It goes against the core philosophy of Tailwind, which emphasizes using utility classes directly in your markup rather than abstracting them away in CSS files.
• Overuse of @apply can create maintainability problems and unexpected CSS issues, leading to technical debt.
• Adam has bluntly said he regrets adding it and wishes he could "uninvent" the feature.
• If you’re concerned about using DaisyUI or any other tool that heavily relies on @apply, this context from Adam himself helps explain why some Tailwind community members hesitate to embrace solutions built on that directive.

Hm... doesn't make it easier 😄 

[Jonathan Lahijani]

https://x.com/adamwathan/status/1559250403547652097

[cst989]

With the ever growing threats from Core Web Vitals and its suggestion to load only the CSS you need, has anyone leveraged ProcessWire (or anything) to load only the Tailwind classes you need for the pages/components you're viewing? 

It comes kind of standard when working in various modern js frameworks but, not so much for a typical php front-end build mostly just relying on wireRenderFile and Procache.

Edited 3 hours ago by cst989

[szabesz]

3 minutes ago, cst989 said:

With the ever growing threats from Core Web Vitals and its suggestion to load only the CSS you need

Sorry for the off topic reply, but I cannot help wondering what will Google do with WordPress sites which take up most of the personal and small company landscape? Will it hide them at the bottom of its search results, just because they fail to adhere to any kind of "Core Web Vitals"?

Don't let me wrong, optimizing for performance is always a good thing, I just cannot imagine how Google envisions forcing everyone to do it according to its own taste.

[cst989]

Oh don't get me wrong, I don't disagree with you. All the CWV are just part of another little black box of Google secrets where we have no idea how much they will really have any effect. Unfortunately though my job involves running into a lot of SEO companies who love to claim credit for every green tick box they can make appear, and blame the algorithm when anything gets worse. And my clients listen to those people blindly...