So the request here is, in the case where I would use a utility framework such as Tailwind, I would have in some cases of daily routine, the need to copy/paste multiple classes per element.
Right now, it seems to create a single class with spaces in between if I copied a bunch of classes with spaces from a html template.
The goal would be to be able to paste a text full of classes in such a way :
class1 class2 class3
in one go, and have those classes applied by understanding (exploding) spaces and create those 3 classes.
This would allow me to copy some Tailwind preconfigured UI elements much faster.
FYI: I use Winden to make all this work.
I added a vote, because it would be nice to copy global classes from one block to another.
However, this is where the utility frameworks like Tailwind fall apart in the pagebuilder space. It takes far too many of the utility classes (and so many clicks) to style elements the way we need (and no way to just quickly scroll through the DOM/HTML and make edits). It’s just simpler to create a custom class.
I’m sure you have your workflow, though, and this fits, but it is just a pain to do.
Again, upvoted because I would love the feature, too.
I totally get it, I myself don’t particularly enjoy this process but it is needed for me to build “quick sites” that don’t need a lot of care or scalability (They can be mine, not for clients only, just saying but also for landing pages for which I already have Dev ui kits all ready to plug in).
It is true the global classes in Cwicly are very convenient and will suit well on custom sites.
You can find an interesting video, at least to me about this: Plain Classes Gutenberg - YouTube that just came out somewhere else.
Would that be hard to integrate @Louis ?
I really believe that’s the missing piece to benefit from a utility framework should one need it.
I am really interested in knowing why people could think that this is not valuable or detrimental.
I understand Cwicly tries to stay away from frameworks but I dislike strong opinions (not pointing anyone in particular) that frameworks and builders are not compatible.
It just depends who uses it and what is the end result.
On top of that, the JIT methods, or similar, keep things nice and lightweight.
While Cwicly can really be a no code CSS way of building sites, I believe it can as well be a code-friendly and utility-friendly base for every kind of project.
It is not damaging the experience for nocode users as they wouldn’t really see the difference if one class or multiple are added in the text field.
Every framework, plus global classes.
Where is this info from? Never heard about that.
Do you have exclusive info about that?
Cwicly even added the external classes feature to use frameworks inside the builder.
The general framework topic probably will get tackled in the future, there were some discussions already.
Tailwind with JIT is something, Louis already threw in a couple of times.
Frameworks and builders are not only not compatible without that particular option this topic is about, but they are also completely useless.
But that’s only my opinion. On the other hand, I can assure you that I’m not alone with it.
I mean it’s fine as it is when building an element. There is the option to just duplicate the block, right?
The real pain kicks in as soon as you need to change the styling.
Without the ability to multiselect blocks, it’s just a waste.
I think you have a general wrong idea about Cwicly.
Because specific features aren’t available yet doesn’t mean that they never will be introduced.
Reading your entire post makes me wonder if we are talking about the same tool.
Definitely agree with @owynter here.
I won’t extend this topic too far, but frameworks are definitely on my roadmap.
But for this, as I have stated somewhere else, I really believe we’ll need “components” instead of blocks as well. Not reusable blocks, but components where you can modify the data/override styles/add classes while having the base of the component stay up to date with its origin.
This is where the framework will have all its meaning I believe.
Components will be a game changer, I strongly believe.
You recently shared some thoughts about it here but couldn’t find anymore (edit: found it, couldn’t remember which term to search for), since I was about to add that particular post in my previous answer.
Great to see you mention it in the exact same context.
I am so glad to read the words “component” and “origin”.
What I have run into is the inability to copy multiple Tailwind classes from block to block. Even if you create a shell. For example if you have a pre existing shell and you need to create a similar one (without altering the pre existing one) you can create another shell like a global class but there is no way to copy all the TW classes at once from the pre existing shell to the new shell.
You also can’t copy more than one TW class at a time from a block. And when there a several classes that becomes a hinderance.
If you have a global class you can easily copy styles from a pre existing global class and ably them to your new class.
Am I missing something?
I would love that after clicking the “+” to add classes we can directly paste a list of TW classes in plain text like in a textarea.
In case there is a duplicated class : ignore it…
In case there is a conflict (ex: p-4 AND p-8) show the class that is not applied / doesn’t affect anything in grey, so we can choose to remove it or to keep it and remove the other one.
It’s in those cases also that class sorting by property would be handy so conflicting classes would be side by side.