Jump to content

Tailwind CSS for ProcessWire Developers

Sergio

By Sergio,
in Dev Talk

 Share

Recommended Posts

3fingers Sr. Member

3fingers

Posted
Posted
50 minutes ago, Krlos said:

Hello, I'm following your video, but apparently the code in the gist is not the same as the video?

In the gist the naming of the main css file is different (kickstart.pcss rather than main.css, the .pcss extension is optional) because at the time of the recording I had already made my previous guide, in which I've used that naming convention, so I prefer not to change it.
Feel free to name your files however you want, just remember to reflect those changes inside the "scripts" object inside package.json.

Link to comment
Share on other sites
  • 7 months later...
zoeck Sr. Member

zoeck

Posted
Posted
10 hours ago, pwired said:

I have been following tailwind css for a while. Can't help it but having so many classes in a tag really clutters up your html. What has become wrong with vanilla css ?

You can also combine corresponding classes, for this purpose there is the "@apply" function.
This makes it possible to keep the code relatively clean ? 

Example vom the Tailwind Docs:
  

.btn {
  @apply px-4 py-2 rounded font-semibold bg-gray-200 text-black;
}

 

Link to comment
Share on other sites
3fingers Sr. Member

3fingers

Posted
Posted
12 hours ago, pwired said:

I have been following tailwind css for a while. Can't help it but having so many classes in a tag really clutters up your html. What has become wrong with vanilla css ?

Nothing wrong with vanilla css at all indeed ?
For me tailwind is just a tool that makes me quicker to write my css declarations and development in general.

Take the above example: 

.btn {
  @apply px-4 py-2 rounded font-semibold bg-gray-200 text-black;
}

In plain css it would be: 

.btn {
  padding: var(--margin-tb) var(--margin-lr);
  border-radius: var(--medium-radius);
  font-weight: 600; // and this might be a custom property too if needed
  background: var(--bg-lighter-gray);
  color: var(--text-black);
}

It's more verbose I think.
I've intentionally wrote css variables to slightly emulate what tailwind does: helping you to create and use a design system, with consistent values at disposal throughout the entire application.

Not to mention purgecss, which is included out of the box, and for me it's a no brainer. It drastically reduce the size of the css to be used in production.

That being said I always find myself in the situation where I have to write my custom css classes, where defaults values I set before are enough no more and need more control.
There is this new option where you can set arbitrary values directly on the html markup (https://tailwindcss.com/docs/adding-custom-styles#using-arbitrary-values) but I'm not really sold and I still prefer to organize them by myself. Having another tool in the box might be convenient from time to time.

  • Like 1
Link to comment
Share on other sites
pwired Hero Member

pwired

Posted
Posted


1)
What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking ?
That would give you the best of 2 worlds !

2)
Having said that, how many percent of all the available tailwind utility classes are really going to be used ?
Certainly not all of them in every website you make, let's say 40% - 50% - 60%  ?

3)
That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap
and bring them in your own utility class framework. That would make things certainly more effective.
How much time would that take ? Sticking to only essential and useful classes, not that long.

 

 

Link to comment
Share on other sites
3fingers Sr. Member

3fingers

Posted
Posted
19 minutes ago, pwired said:

What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking ?
That would give you the best of 2 worlds !

I've found myself that the most useful classes are the ones dedicated to wireframe the layout itself, like margins and paddings. Using them in early stages of the blocking phase seem to be the most effective way for me. So I tend to do the opposite of what you are suggesting: utility classes first and layout tweaking with custom rules later (if needed).

19 minutes ago, pwired said:

Having said that, how many percent of all the available tailwind utility classes are really going to be used ?
Certainly not all of them in every website you make, let's say 40% - 50% - 60%  ?

There is plenty of utility classes I never had to use, and that's ok. This is also true for vanilla css declarations as well, it all depends on the specific project. To me it's not about how many utility classes I would use, but how many of them I can reuse inside a single project, avoding inconsistencies all over the place. Having the ability to tweak them in one single configuration file is a bonus. Of course this is also true if you are smart enough to go with "pure" css custom variables inside the :root selector of your css.

19 minutes ago, pwired said:

That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap
and bring them in your own utility class framework. That would make things certainly more effective.
How much time would that take ? Sticking to only essential and useful classes, not that long.

This is certainly an option, if you have found something inside Bootstrap, Bulma or whatever is missing from Tailwind.
I don't see the point anyway, because with the new jit mode from Tailwind you will have just the utility classes baked inside your "dist" css, without any bloating useless css.

  • Like 1
Link to comment
Share on other sites
teppo Hero Member

teppo

Posted
Posted
On 12/12/2021 at 10:41 PM, pwired said:

I have been following tailwind css for a while. Can't help it but having so many classes in a tag really clutters up your html. What has become wrong with vanilla css ?

I've been using Tailwind for years, yet there are still both those days that I really enjoy using it, and others when I wonder if it really makes sense, so I get what you're saying. Also: even though we use it for just about all of our projects nowadays, we often combine it with "custom" CSS classes (mostly BEM style), simply because Tailwind isn't always the correct tool for the job ?‍♂️

Others have probably said it already, but for me/us the benefits of Tailwind boil down to...

  1. super fast development, particularly when mocking things up / designing in the browser,
  2. common set of tools and guidelines, which is very nice when working in a team (having to dig into an older project that doesn't use Tailwind is a bit of a pain), and
  3. superb efficiency — by which I mean that using Tailwind results in very small CSS files, in most cases much smaller than I would get by writing my own vanilla CSS.

There are a couple of things I'd view as downsides: a) markup becomes entangled with styles, and b) sometimes it feels like I'm just learning alternative ways to do the stuff I would already know how to do with vanilla CSS. First one is something that, in my opinion, can't be completely avoided, but using components for shared sets of classes helps a lot. Second issue becomes less of an issue day by day.

Other than that, I'm quite happy with Tailwind, and it suits my workflow very nicely. It's not the perfect fit for everyone (or for every project), and that's fine too ?

  • "What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking?"
    • Well, we use a combination of custom CSS and Tailwind already, but the literal "layout" part is one that's actually so efficient to do with Tailwind that I wouldn't bother doing it in vanilla CSS anymore. In my experience changes to the layout are often easier to implement with Tailwind than with vanilla CSS, and the resulting markup is actually quite clean.
  • "Having said that, how many percent of all the available tailwind utility classes are really going to be used?"
    • It doesn't really matter how much of Tailwind I / we use. Thanks to the tree shaking logic the "compiled" result only includes what is necessary. There's zero overhead in having a large toolbox but not using each tool for every project.
  • "That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap and bring them in your own utility class framework. That would make things certainly more effective."
    • Exactly how would this make things more effective? We're in the business of building custom sites and/or applications, so pre-built components offered by a front-end framework won't help much (if at all), at which point — from my point of view — all Bootstrap and likes can offer is a very limited set of utility-first tools. Sure, we use prebuilt tools elsewhere (Vuetify for PWA apps etc.) but for custom-built sites Tailwind is (IMHO) a better fit.
  • Like 7
Link to comment
Share on other sites
3fingers Sr. Member

3fingers

Posted
Posted
2 hours ago, Ivan Gretsky said:

Is tailwind suitable for theming somehow? Same markup, different styles? I would guess it is not. But maybe I am missing something?

I tried to understand your question but I'm missing something for sure. Can you elaborate a bit deeper please? ?
As a quick guess, is this page something you were looking for?

Link to comment
Share on other sites
3fingers Sr. Member

3fingers

Posted
Posted
51 minutes ago, Ivan Gretsky said:

Like you have your primary color as blue and the client wants to have it green.

That can be easily done changing colour variables inside tailwind.config.js as suggested on my previous post. In addition to that it might be useful, for theming purpose, to create a single preset for every theme you want to have, and switch between them per project-basis. More here https://tailwindcss.com/docs/presets

51 minutes ago, Ivan Gretsky said:

Or you want to  override color just for a part of the site.

Not something possible out of the box as far as I am aware of. Utility variables are top level and not tied directly to custom sections.

  • Like 1
Link to comment
Share on other sites
Ivan Gretsky Hero Member

Ivan Gretsky

Posted
Posted
1 hour ago, 3fingers said:

Not something possible out of the box as far as I am aware of. Utility variables are top level and not tied directly to custom sections.

Maybe css vars could help.

Thanks for the insights. I finally understood that colors can be set as primary instead of blue in the config) But still all examples I've seen do use named colors. I guess it is a trade-off of using utility-first approach.

Link to comment
Share on other sites
teppo Hero Member

teppo

Posted
Posted
10 hours ago, Ivan Gretsky said:

I finally understood that colors can be set as primary instead of blue in the config) But still all examples I've seen do use named colors. I guess it is a trade-off of using utility-first approach.

Not sure how common this sort of practice is, but we always define custom colours for each project — usually with generic names such as brand-1, brand-2, etc. (unless the client has named colours or a lot of colours, in which case more specific naming helps). In fact in most cases I only use two colours from the default palette: black and white. Everything else (including shades of gray) are either custom colours, or just black/white with specific opacity applied ?

Same thing goes with paddings: while we use the default spacing scale, there are always a few "project specific" values; half, single, double, triple, etc. Usually these are pretty straightforward (single = 1rem, etc.) but sticking to predefined, named values does make it a tad easier to make changes later.

11 hours ago, Ivan Gretsky said:

Or you want to  override color just for a part of the site.

I don't think there's a built-in way for this. Depending on the specific use case I'd probably pick one of two options:

  • If it's just a few colours etc. that need to change, add those to the shared theme config file for the site and handle the "colour theme" in code.
  • If there are a lot of changes and/or for some other reason you want to clearly separate styles for different parts of the site, create a separate Tailwind config file and adjust your build process accordingly. How that would work depends on what kind of build process is in use, but generally speaking it shouldn't be too difficult ?

If you google something like "tailwind multiple themes", you'll probably find other solutions as well. I've never needed this type of functionality, so haven't given it much thought.

  • Like 2
Link to comment
Share on other sites
  • 5 months later...
wbmnfktr Hero Member

wbmnfktr

Posted
Posted

More than a year ago I said I would try TailwindCSS... now it finally happened and... and the result is disastrous!

 

Well... disastrous for my opinion back then and my thoughts about it until a few weeks back.

I am quite surprised and happy with the result, to be honest.

I did a rebuild of an ongoing side-project, with a full rebuild of the whole site structure all the way through to any breakpoints (CSS only, HTML was kept except additional classes). Yet some parts are still outside of TailwindCSS as those are really custom and are way better placed in an additional CSS file. Even though you can customize TailwindCSS to almost all of your needs but I didn't want to bother with it for now.

The change in file size is quite dramatic... or even super awesome.
However you want to see it.

I went from...

  • 59kb (the whole project)

down to

  • 17kb (structure - based on TailwindCSS CLI generated .css file) PLUS
  • 5kb custom CSS for colors, custom properties PLUS
  • 10kb custom CSS for icons, backgrounds, and fonts PLUS
  • unknown size of additional kb within HTML due to those TailwindCSS classes

tailwind-vanilla-compare-file-size.png.d8b74e7341fe2375540d2125f0cc9239.png

Ignore those other files as those are helpers or part of other instances within that setup.

Which is in total:

  • 32kb for the full project, all pages, all icons, all fonts.

Yet... the whole setup isn't ready for production right now as my setup only really works with 11ty as a middle-man for now and not within my PW workflows... but that's another story. There are probably even more things I could optimise in terms of fonts, icons and custom classes for colors.

But for now... WOW... I always was against those utility frameworks and didn't like them at all.
I am and always was a VanillaCSS Purist... didn't ever really like Bootstrap, UIKIT or anything like that, but TailwindCSS could and might have changed my mind. 

From now on... I might have to think and work different for some or another reason.
Right now my test was built on a project I really knew in and out with all its details.
Let's see how it works out in a real and new project.

Results based on: TailwindCSS 3.1.2 (latest - as of now, 2022-06-14. all file sizes unzipped, without plugins like Typography)

  • Like 4
Link to comment
Share on other sites
  • 3 weeks later...
Jonathan Lahijani Hero Member

Jonathan Lahijani

Posted
Posted

If you're looking for a JS library that pairs well with Tailwind, might I recommend Preline, which I just found on Hacker News:
https://preline.co/

Another option includes Flowbite, but at the time of this writing, Preline's JS goes a bit further and has more components and more options (such as offcanvas, mega menu):
https://flowbite.com/

There's also Alpine Components if you're into Alpine, however it's commercial:
https://alpinejs.dev/components

I like Alpine.js, but the "locality of behavior" approach it takes for these common components is not my style.  I do use it elsewhere however.

-

Lastly, there's Headless UI, but that probably won't fit with a typical ProcessWire frontend unless you are using React or Vue:
https://headlessui.com/

I wish Headless UI had a Alpine.js version, but the author of Tailwind ultimately scrapped the idea (it was mentioned in a Tweet thread somewhere).  This would have been my go-to approach, assuming it was comprehensive enough.  But there's many options as stated above.

  • Like 4
Link to comment
Share on other sites
Jonathan Lahijani Hero Member

Jonathan Lahijani

Posted
Posted
On 7/5/2022 at 6:06 PM, Jonathan Lahijani said:

Lastly, there's Headless UI, but that probably won't fit with a typical ProcessWire frontend unless you are using React or Vue:
https://headlessui.com/

I wish Headless UI had a Alpine.js version, but the author of Tailwind ultimately scrapped the idea (it was mentioned in a Tweet thread somewhere).  This would have been my go-to approach, assuming it was comprehensive enough.  But there's many options as stated above.

The author of Alpine.js and Alpine Components (Caleb Porzio) mentioned the following in an email announcement today:

Quote

In other news, We're working on an Alpine version of Headless UI. Headless UI is the library that Tailwind UI uses for anything that needs JavaScript.

Unfortunately, Headless UI only supports Vue and React, so anyone not using those tools has to implement the components themselves (I don't have to tell you how hard that can be).

Because Tailwind UI is so good and so many of us use it, we're going to build a pound-for-pound copy of it for Alpine, making it trivial to use anything Tailwind UI with Alpine.

I'll let you know more as we keep building, but it will likely be available to "Alpine Components" purchasers during development, and then eventually made free when all the components are finished. At least that's what I'm thinking for now.

So, that will in fact be a fourth option. ?

On 7/6/2022 at 9:04 AM, kongondo said:

The examples on their website don't seem to work? 

Thanks for these resources! 

Works for me.

  • Like 1
Link to comment
Share on other sites
  • 3 months later...
  • 2 months later...
MarkE Hero Member

MarkE

Posted
Posted

I have a little home-made pagebuilder that is based on RockFrontend and Tailwind and have a few observations that might (or not) be of interest.

  1. Tailwind works really well with Latte. The result is (to my mind) concise and understandable code that is easily encapsulated.
  2. I tried some of the plugin components etc. but was generally disappointed. As is usually the case with these things, you get a load of baggage you didn't really want and then you try and customise it slightly and it is not easy. I ended up just building my own components with Latte, Tailwind and a bit of custom vanilla js (with a bit of help from various examples on the www). For example, I built a general-pupose carousel template that can be called via a Latte {include file} with options, e.g.: 
    {include 
    $config->paths->templates . 'motif_layouts/latte_blocks/motif_carousel.latte', 
    imagePages: $page->motif_image_page, 
    modal: true,
}

    and  

    {include 
    $config->paths->templates . 'motif_layouts/latte_blocks/motif_carousel.latte',
    imagePages: $page->motif_image_page,
    start: $page->motif_image_page->first,
    autoCycle: ['speed' => 5000]
}
  3. My pagebuilder makes extensive use of css grid-area-templates which are not present in Tailwind. I thought this might be a bit of a problem, but was pleasantly surprised that the css file reduced from this: 
    .image-text .has-image {
  /*grid-area: content;*/
  display: grid;
  grid-template-columns: auto;
  gap: 20px;
  grid-template-areas:
    "image"
    "text";
}

@media (min-width: 500px) {

  .image-text .has-image:not(.image-right) {
    /*grid-area: content;*/
    display: grid;
    grid-template-columns: 1fr 5fr;
    gap: 20px;
    grid-template-areas:
    "image text"
    "....  text";
  }

  .image-text .has-image.image-right {
    /*grid-area: content;*/
    display: grid;
    grid-template-columns: 5fr 1fr;
    gap: 20px;
    grid-template-areas:
    "text image"
    "text  ....";
  }

}
.image-text .no-image{
  /*grid-area: content;*/
  display: grid;
  grid-template-columns: auto;
  grid-template-areas:
    "text";
}

.image-text img{
  grid-area: image;
}
.image-text div#body{
  grid-area: text;
}

    to this: 

    .image-text {
  --stacked:      "image"
                  "text";
  --image-left:   "image text"
                  "....  text";
  --image-right:  "text image"
                  "text  ....";
  --text-only:         "text";
}

.image-text img{
  grid-area: image;
}
.image-text div[id*='body']{
  grid-area: text;
}

    with only a marginal increase in the html (using arbitrary properties and values) and (I think) an increase in clarity: 

    <div n:class= "$imgs > 0 ? '[grid-template-areas:var(--stacked)]' : '[grid-template-areas:var(--text-only)]', 
              ($imgs > 0 && $page->motif_toggle == 0) ? 'sm:[grid-template-areas:var(--image-right)] sm:grid-cols-[5fr_1fr]',
              ($imgs > 0 && $page->motif_toggle == 1) ? 'sm:[grid-template-areas:var(--image-left)] sm:grid-cols-[1fr_5fr]', 
              grid, gap-5">

    Note that you need to include these type of class names in quote marks or Latte gets confused.

  4. The bit that worried me most was where I needed styling to be dependent on php variables. Some commentators have said that this presents a problem for Tailwind because it creates the stylesheet before the variables are known. However, the work-round is quite simple, with an in-line style tag to create css vars like this:
      

    <style>
  #gallery-item-{$imgPage->id} {
    --w: {$imgDisplayWidth|noescape}{$heightArray[1]}; 
    --w2: {$expandWidth|noescape}{$heightArray[1]};
    --wh: {$halfWidth|noescape}{$heightArray[1]};
    --wq: {$quarterWidth|noescape}{$heightArray[1]};
    --h: {$height|noescape};
    --h2: {$expandHeight|noescape};
  }
</style>

    which then can be used directly: 

    class="w-[var(--w)] hover:w-[var(--w2)]"

    It may be that there are better ways of doing some of this, but I was pleasantly surprised that each time I looked at a bit of slightly involved css and html and thought 'how the hell am I going to do that in Tailwind?', the answer was much shorter and clearer code. In particular, Latte works well with Tailwind throught the power of the n:class tag.
     

  • Like 5
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...