Because it is a <button>
But this would rather fall under Global Classes?
We would also have to have a special class added to every Cwicly button, which would rather go against the whole process no?
I’m more than happy to hear your thoughts
Just adding, if you want to style links in this manner, then the Links styling is perfectly suited.
Just to add to this @AI_Vegas.
I notice you set btn-main as the Class for the block.
This is fine if you don’t make any particular changes to the block, but otherwise I would recommend adding this to the Additional Class instead so that the properties you apply to that particular block aren’t applied to all btn-main.
Right. I think for now the definition of “Button” is the problem here.
I am not sure if it goes against the process. If you think so, then maybe the global Option should be renamed to “HTML Button” or something to prevent confusion.
Honestly i am not sure if we need a global styling section for button elements if they are not used by Cwickly nor by native Gutenberg. There are many other HTML elements no global styling UI is provided for. So why buttons? Hm. I am unsure about that.
Maybe just add possibility to change tag (div / a / button) for this element?
And it would be nice if we had an inner wrapper for the text of a Cwicly Button. This would make more complex stylings possible like animated backgrounds on hover (with :before and :after).
I had to build my buttons out of div block (tag changed to ‘button’) with an inner div in the current project instead of using the button block.
The Button Block uses the same Icon as the Global Button Styling which makes the matter even more misleading:
Hi @michelyweb,
Indeed, your points are right, and this can be confusing.
We’ll be changing this in the next update.
Thanks.
Following this thread, I think that applying a tag of button automatically to the button element when added to the page would make more sense. That way any global button style created is applied automatically and then if you need to be more specific then just add the additional class name from the global button.
1 Like
I’ll add to this list that buttons certainly stand out as a scenario where unified theming capabilities between Cwicly and other Wordpress blocks (certainly native buttons at least) would be really handy. Also, there’s no way currently to set an icon on a global class, even though that’s a theming feature of Cwicly buttons, so rather than renaming the “Buttons” global styling to “HTML Buttons”, please do consider consolidating all these needs/requests into a revamped button theming global styling control that handles all of these scenarios.
2 Likes
IMO, a new “Button Style” dropdown on the button blocks could be a good fit to differentiate classes from the styles set in the global theming, like so:
2 Likes
That was actually my initial suggestion and I still think that it would make sense, since we are able to create more than just one default style.
In the dropdown, instead of the class name, the actual element name which you set by yourself, could be shown.
I was going to record a quick video explaining my confusion, but everyone here pretty much hit every point that I had.
@avunu this is exactly how I was imagining this feature would work.
The other factor is that users get primed to think this is how it works because of Block Typography.
With Block Typography, you create a few styles and then can apply them by clicking the globe icon when editing elements.
Buttons, Links, Inputs etc. have the exact same UI, but then work completely differently.
1 Like
The Problem still there right ?
A Button block, in the majority of cases, is an <a>.
The whole point of Global Elements is to allow you to apply these same styles to other elements that might not be controlled by Cwicly → unifying your website the proper way… I fail to see the point you’re trying to bring up here.
I’m sorry you feel this way, and hope you know that this isn’t true.
In any case, the issue I have with your proposition is simple: it removes freedom in design. Cwicly has always tried to be as close to code as possible.
As I have mentioned numerous times:
You simply cannot do that with if you went the block typography way.
Definitely something we can work towards
@Louis For what it’s worth, I’d still probably agree with @ace (and my former self) here.
As a new user, I remember this creating quite a bit of confusion when trying to understand how the Global Styles section worked.
The main issue is that Block Typography are presets which you can choose at the block level, and then all the rest are base styles which you can apply to HTML tags/classes.
How they function is fundamentally different, and that’s what creates the confusion.
It could be worth exploring simply moving the Block Typography to the Typography panel.
Otherwise, I think it’d be a better user experience to either have all Elements support presets, or all Elements assigned to an HTML tag/class (or both).
I hope that makes sense.
1 Like
Whether it makes sense or not.
Block presets (pre-defined styles, global classes, relative styling, etc.) is a topic, I read about here and there and there were some discussions about it already.
I have the feeling that this doesn’t fit into Cwicly’s approach/philosophy and from my perspective, it isn’t required necessarily.
But I also have the feeling that quite a few users would vote for it, in case there is a feature request.
Adding (let’s be honest, it’d be rather forcing) classes to each block, like every other tool does, no matter they are used or make sense, would be a massive step backwards in my opinion.
A potential block presets area could handle that, if the user requires so.
In the long run, I also see Cwicly as a tool for total beginners.
While improvements were already made, it isn’t just there yet in that regard and maybe addressing this topic (in whatever form) could be another step towards it.
1 Like