I finally found a bit of time to test Tailwind in Cwicly, and though I find its implementation very well done, I still have a hard time knowing if this kind of utility first (-only?) is really suited for me. If I can completely switch, or if I need to mix it with some other concept to achieve what I need (and how), or if I have to forget it at the moment.
What I really like is:
- The visual feedback of the TW classes, be it in Cwicly’s inspector or HTML code. (But I have not yet tested on a real life project, so the multiplication of classes and duplication might annoy me in the end… Time could tell!)
- The consistency of standardized classes that allow sharing elements with simple HTML copy/paste (or “stealing” from any TW website for inspiration or starting point).
- The community, templates, bridges with Figma and I guess many other tools.
- Adopting some industry standard and learning a new workflow, which can’t hurt
- Cwicly in charge of everything in the background (like purge)!
What I don’t like:
- The inability (well, it seems, but prove me wrong) to define global styles or to apply styles to third party elements or programatically (for instance to style my form plugin buttons like other buttons or use global classes/variables in code blocks).
- The multitude of values to choose from for a property instead of more semantic values (that I personally set through CSS variables and utility classes in my own framework), which could lead to inconsistency within the same site.
I understand that Cwicly components remove the need for global styles in a lot of cases, that Cwicly shells can solve other usecases, but it seems to me that gaps remain.
So I’ll share here 3 fundamental requests that I couldn’t achieve, to see if I’m just missing something or if I’m just not TW-compatible, or if I have to wait for updates.
1- Global style base elements
How do I use the Cwicly’s global styles tab in TW context?
If TW philosophy is utility-only, then how can I define global styles for sections or typography?
Do I have to use
2- Unifying all buttons sitewide, including:
- Cwicly buttons (be it native button or wrapped in a component),
- Wordpress buttons (for the client to use in its articles for instance),
- form plugins buttons,
- PHP-coded links/buttons in code blocks (custom queries or actually any code).
In my own system, I have some custom CSS applied to .cc-btn, .my-form-button, .wp-button, etc, and I can style anything with it. And I have some .btn-outline, .btn-brand, .btn-dark, etc, if I need variations.
How can I do that with Cwicly/Tailwind, please?
Again, do I have to look into the
3- Limit property values to a custom semantic set
For instance, I only want 5 custom font sizes or spaces based on CSS variables.
(Knowing that I can later use random custom values anyway if I need it, either with TW class or Cwicly class styling.)
Do I have to change TW configuration in Cwicly?
But is it really TW philosophy?
And if I do this, can I set some fallback values/classes when sharing components with others who don’t have my configuration so that it can render pretty good anyway?
Well, you see, I’m just a total newbie with TW, and I couldn’t find my answers in Cwicly’s videos or @Louis’s great lives.
Obviously this update is a first step towards some more refined and complete system, but I would like to understand if I can jump in or stay with my workflow.
I would love to be convinced and get rid of my framework (or at least a large part), simplify my workflow, have more consistency in all my work, easily share snippets with others, and leave all the work to Cwicly and Tailwind
Thanks in advance and congrats to the team for this awesome piece of work, like always.