Exploring the next phase of Tailwind with Global Styles

Hello everyone,

In June 2023, as I introduced Cwicly components, I hinted at the team’s plan to launch a Tailwind integration.

The response was overwhelmingly positive, affirming the value of the integration.
Our progress on the integration persisted, with significant features being rolled out along the journey.

Finally, last week marked the culmination of our efforts as we unveiled the Tailwind integration in Cwicly 1.4.
The reception it has garnered is far more than what we had anticipated, to say the least!

As you can imagine, this marks the initial phase of the Tailwind integration, and we have even more exciting developments on the horizon.

I’m so excited to see that a number of you are seriously considering completely switching their current framework for Tailwind and have concerns about how to approach global styling and custom values with a full switch.

As planned, the next step of the Tailwind implementation revolves around global styles.
In view of the demand, we are making this step our priority for the next important Cwicly release.

This means that you’ll soon be able to apply Tailwind values to Cwicly global styles, ensuring consistency and universality for third-party elements.

A variable manager is also planned for a later date for those who want that extra flexibility automatically synchronized with Tailwind.

Please don’t hesitate to share your feedback and insights with me.

Thanks once again for your support and trust!

Have a great week.



Thank you @Louis, you are certainly on point with global styles it seems to be the next logical step to make the TW integration successful.
Bear in mind that not everyone is aligned with the purpose of using TW as the preferred framework, are all the developments tight to the use of tailwind exclusively?
Are you willing to provide more detailed instructions or “proper education” like you said in the last live, over the matters of using tailwind with quicly in an effective way?

It would be good to know about best practices, your practices and workflow, to have more old school videos from the developer team teaching how to use every single aspects of the tools in any specific category.
We have some old ones though, most unlisted and scattered around the documentation.


:+1: very cool. You are solving most of the pain points that Tailwind in a Page Builder context could cause … now let’s educate on the upsides and benefits.


Hi @Louis,

Thanks for begin so reactive and talkative about this.

I admit I have a hard time guessing how everything will work in the end, but as I trust you and the team, I’m very willing to dig deeper in the HTML markup only solutions.

Having worked for years with separation of concerns and vanilla CSS or JS, I admit I won’t accept this right away, for different reasons like readability, debugging or performances, or simply because I have to change all my workflow :rofl:
But I’m very eager to be convinced and switch to this philosophy if it’s worth (especially regarding performances and long term durability, because I can work out the rest myself).

I have had Tailwind, Svelte and other HTML based frameworks in the radar for a pretty long time, but as I didn’t see anything good coming within Wordpress, I never took the time to explore.

With Cwicly pushing the walls inside WP, I guess new doors are opening :slight_smile:

Personally my main concerns about global styling are:

  • Theming: I like to have a starter CSS config like a default skin, that everything is clean and automatic for a new project, that I can configure inside it my fluid system or link/buttons appearance in seconds.

  • Tweaking: I like CSS because for instance I can add a ::before on all my h2 headings sitewide in a blink, or style all the links in a specific page or container.

  • Exporting: I can copy/paste my CSS file to a new site and start directly working on a clean and functional starter site.

That said, I actually would be more than willing to get rid of my (S)CSS files, to stop digging in stylesheets, different code blocks CSS tabs, or any block advanced tabs to find/debug styling.

So if Cwicly’s UI can help us THEMING EVERYTHING GLOBALLY in global styles tab, it will be huge.

As for the TWEAKING, I wonder how I will be able to select and modify what I need, since if the philosophy is not to use custom global classes, selectors will be a bit harder to build. But I guess there are some ways to do this that I can’t imagine now.


1 Like

As you guys already know I’m blown away by what you have created. It has already far exceeded my expectations - so simply to say that I cannot wait to see what you come up with next.
I am currently working on my 2 largest projects ever, and I’m determined to now get these fully migrated to Cwicly and Tailwind - so hearing that you are prioritising implementing global styles with Tailwind only reaffirms to me that I am making the correct decision.

Keep up the great work - and thank you


1 Like

Thanks @Louis , I was wondering about this when playing around with Tailwind in Cwicly. The Tailwind docs say you can do this manually in the base layer using @apply to apply classes to the body and heading tags, for example, but it would be nice to be able to do everything within the Cwicly interface. Especially since there’s already a global styles area for text, headings, etc…

The one thing that will take some getting used to for me, is the lack of variables in TW, so it’s nice to see you have some ideas for that as well.


@msguerra74 , in TW, you can use variables that you define via CSS.
You introduce these variables into the classes and if you modify the variables, the appearance of the web page is automatically modified (spacing, colors, …).


I’ve been away for over a year and got really excited when I read that Cwicly added Tailwind.
That was nothing compared to what I discovered after reading the docs for 30 minutes!
Impressive advancements.
I love the way you built the Tailwind UI merge by looking at the video presentation but that wouldn’t be quite perfect without components.
Then I saw your components with nested system, shells and code blocks being available too.
I can’t wait to test and see if the themer and ACF relations got improvements too.
At this point I only need a linter and Emmet and I’m good to go :smiley:

By the way, will the ACF pro licensing take a hit with Delicious Brains announcement about 3rd party inclusion last week?
I hope it won’t and you don’t consider a switch to metabox for instance.

That’s an amazing work IMO @Louis and team.

1 Like

Please see @Louis’s response in this thread:

1 Like

Honestly, I failed to notice how packed of information are the youtube lives, I must also say that its a bit demanding of attention listening @Louis and there is not always enough time to watch the entire videos.
After I dig into some of them I expect to be better educated on the features and processes.
Cwicly is indeed an incredible tool in a time that is needed, though it has its learning curve.

Perhaps certain lessons in some of those lives could be synthetized in smaller chunks of information that could be added to the docs site. in video library form.

I get there are some priorities and the team is delivering hell of updates each time.

I apologize if I am demanding in matters that may only concern myself.

1 Like

Thanks, I was mostly wondering if there was a way to tap into the default classes without having to manually add them. Like maybe some setting I wasn’t aware of, or a plugin. Classes are great unless you can’t get to the element to add them. For example, if you wanted to add a class to a form element generated by another plugin, or something similar. Usually, you can add custom CSS to assign styles while still tapping into your own color system.

This works, like you mentioned, by modifying the TW CSS, but I was just wondering if there were variables already availble to use without defining them.

Thank you! I just started to set things up with Tailwind and was jumping on here to see if there was any documentation on the global styles for tailwind. Thanks i thought I was missing something, looking forward to that addition!

Also, can you provide me a little insight on the gird builder. What are the benefits of having tailwind on for the grid set up? And how does it work??? I see that i can add columns and rows… but I am lost beyond that. So not sure if we should have TW on or off for grid building?

Thanks so much, this is really elegant and impressive. Keep up the great work. And maybe hire some more devs to help you get it done faster LOL we cant get enough. HAHAHA.

I think @artisan will soon be working on video materials for Cwicly and TailwindCSS so maybe this would be a good topic for a video - how to style form plugins and woocommerce.
By the way - woocommerce is completely moving to blocks: WooCommerce Checkout Page

Thanks for the update!

I can’t wait to see how Cwicly integrates Tailwind with global style. If not already, Cwicly will definitely be the best builder for TailwindCSS.

I will share with you the interesting components that I found.


Here is another:

It’s a bit funny that both addons for Tailwind go the semantic route :see_no_evil:

1 Like

Found this one a few days ago, exploring TW ecosystem, I love it!

And I’m not so surprised that some TW addons go semantic, because unlike a lot of people seem to believe, TW can be very semantic thanks to the use of tokens and its customization process.

For instance, when defining colors in Cwicly with semantic tokens like brand, primary, etc, (custom colors or based on the more low-level color actual names like blue-500), you can use all TW color property classes with semantic colors.

Other example with spaces. I replace all TW spaces, which I don’t use, with my semantic space design:

    spacing: {
      '2xs': 'var(--space-2xs)',
      xs: 'var(--space-xs)',
      sm: 'var(--space-sm)',
      md: 'var(--space-md)',
      lg: 'var(--space-lg)',
      xl: 'var(--space-xl)',
      '2xl': 'var(--space-2xl)',
      section: 'var(--space-xl)',
      container: 'var(--space-lg)',
      content: 'var(--space-md)',
      grid: 'var(--space-sm)',
      form: 'var(--space-xs)',

The same goes for font sizes, shadows, border radius, etc.

So if you use TW like a “utility” tool with “semantic” tokens, it ends up in a pretty very well balanced hybrid system :wink:

As for semantic classes like btn, btn-primary, etc, I need a bit more practice. It might goes against TW philosophy, and could be avoided with components, but I have some examples in mind that would need global classes, like global styling containers (div, sections…), which can’t be components.


Quick user interface suggestion for the updates to TW. I am sure you are already considering this and plan to address it, but it would be good to make the TW Styles and CY styles more distinct in that I am doing a lot of turning on and off the TW view to check for underlying styles from CY. If both are active it doesn’t function correctly. JLOVE it all BTW. Great job @Louis

Does that mean that you can’t use style elements that are not in tailwind, if you use tailwind as well? That would be good to know, since I’m still dithering about using tailwind…