I just wanted to share some random thoughts on the ongoing development of cwicly and open a discussion about some things:
First of all I want to express one more time how impressive the latest updates of cwicly are. Components, color picker, dark mode, etc…! And for me the most impressive of all that is that the cwicly team still finds time to polish the product and fix bugs! Huge thanks to @Louis and the whole team!
With that said, there are a few things that are possibly already on the radar of the team, but I thought the earlier I share my thoughts the earlier a real discussion about different opinions can start (if not somewhere else already exists)
The new color picker, Although it is very impressive there is one thing that comes to my mind when working with it. The shades are now generated in a way that one could assume that this is a preparation for the ongoing tailwind integration (1-900 shades). However if that’s the case there are two things I’m really missing and would like to see there:
normally I generate my color shades from a specific color. I paste my hex code and assume that the pasted color is my „main“ color, which is for me the -500 shade. Cwicly seems to generate the shades based on the lightness of the color, which is definitely not wrong and a cool approach. But when working with brand colors I want my 500 shade to be exactly the color of the brand/company and to have the option to switch to lighter and darker versions of that color.
This is probably just a personal preference as there is nowhere said that the -500 color has to be the exact „main“ color. But I find it as it is working now a bit randomly. I normally do have a lot of predefined tailwind stuff which I would like to reproduce (maybe later import it as HTML) where I would like to rely on some consistency regarding that color shades throughout installations.
Another thing I wasn’t able to find and which I often use in tailwind id defining the „DEFAULT“ attribute in the tailwind config when working with colors. That leads to a generated class „*-primary“ without pasting the „-500“ shade number, just a shorthand for the company/brand color, but in my opinion very useful. Nothing has be announced yet about tailwind (for example if we can edit our own tailwind config etc) but I guess that the new color picker will play a role in the configuration of colors.
What are your thoughts on that topic? I don’t want to generate any pressure or any assumptions without seeing anything of the tw integration yet, but as described in the beginning - maybe it’s useful!
The exact color is the main color and the 50-950 colors are the shades, where the 500 color is the middle shade. So wouldn’t you just pick the main color for the main color?
In my opinion the main color should be the middle shade, because from there I have the possibility to use the darker or the lighter shades. Not sure if I got your answer right to be honest, do you prefer something different?
Thanks for thinking about this and taking the time to put it down. Always nice to have some input and suggestions on upcoming features! This really helps us make sure we’re not missing out on anything important.
For the palette generation, we did go over this quite a few time with the team and decided to stick with the auto placement of the base colour. In my experience, a provided 500 weight colour rarely ends up being 500 in a 50-950 context and the generation ends up giving us a much better range of usable colours.
The generator is definitely not perfect and is only meant to be a starting point for more extended tweaks. That being said, it does base itself closely on the Tailwind default palettes in terms of progression etc.
Cwicly palettes and colours will be available in the Tailwind integration.
However, if you feel more comfortable with a custom palette, we will be supporting custom configurations also.
If I haven’t misunderstood your second point, I think @msguerra74 did point out the solution we have provided. The base colour is always available within the colour picker as a separate entity within the main global colours list.
If I have missed anything, please don’t hesitate to let me know.
If, for example, your main color was black, or some dark or light color, then the shades wouldn’t scale properly if 500 was the main color, since everything above/below that color would essentially all be black/white.
This way you pick your color and it will generate a full spectrum of shades while keeping your main color untouched. So I can pick white as my main color and have a full palette of all the shades ranging from almost white to almost black. Hope this makes sense, but I really think the current implementation is the best way. Additionally, I believe you can manually change any shade, or use the modification tab to create whatever light or dark shades you want, without having to even activate the regular palette.
That’s definitely a point. But still if I develop anything, whether it’s only reusable components or something more complex (I tend to add some custom Gutenberg blocks for fetching and showing data from our own apis for example) I still have the problem that I want to create my components as reusable and easy to use as possible.
Imagine a scenario where you rely on a custom created code in an external editor which you may want to load on your site (that assumes that cwicly will scan all blocks/page content for tailwind classes of course). Of course I could hard code my color shade there, but what if I want to reuse it on several different sites and I may not know which shade is the correct one I have to bring in some standardization. Meaning not only have my main color in place (500) but also being able to use lighter/darker shades from that color.
Of course it could happen then that my hover effect doesn’t differ from my main color much, but I prefer a standardized component using the correct main colors instead using the wrong main color and always have correct lighter/darker shapes in place to be honest.
Hopefully it’s clear what I mean. And yes, I could probably generate a variable for my main color, but then I still don’t know, if I use that color, if for example the 600 shade is lighter or darker as this specific color …
