In Gutenberg, I can also assign default classes for individual blocks, which are always assigned when the block is inserted.
This makes sense, for example, when styling elements (tags) as little as possible.
I got into the habit of doing this in order to have to overwrite as few of the old / base styles as possible when applying other styles.
Example:
The default h2 has a “border-left: 2px solid red”, so very special…
<h2 class="h2">Headline 2</h2>
later:
Here you don’t want do override with “border: none”, so just change the class and do your stylings;
It is also helpful if you want to tag a headline with a different tag for SEO reasons (say h2 instead of h3), but still want it to look / style it like all the others of this level (like h3 in this example).
PS: I saw that I can assign classes for elements like images (img tag), but even there I can’t set a class as default assignment. Yes unfortunately to my shame I haven’t even managed to assign these classes manually and I can’t find any info in the docs or the video about it either. I had suspected them in the global classes …
It’s something I was thinking about for quite a decent amount of time and in theory, it sounds like a really nice idea.
In the end of the day, for me, these are just block defaults which would be removed in far too many cases.
To be honest, your examples don’t make sense either. Your h tag style is something which never happens in real world, in your second example, you most likely remove the class in 9 out of 10 cases, because it’s far too specific.
Even if your examples might not be the best ones to make your point clear, choosing different ones that fit more won’t make things better.
I understand why people would find it useful.
Using “clean blocks” and global classes is the more efficient way on long-run, at least for me.
I think some would need to experience it in practice first to get the idea and realize it.
A discussion would be quite interesting to see how other users feel about it.
There was already a discussion about it, if you are interested.
I want to add that Cwicly evolved quite a bit since then and I came to the conclusion that it still is a good idea. But only in theory.
Well, I’m using this technique (resetting all elements and use only classes) quite a long time and I don’t know why my examples are doesn’t make sense. There are no problems with too much specificity here, since I can remove a class should I want to style only the element in general in special cases.
Another example is clean up the ul/ol and li styles.
In the current implementation of Cwicly, I would have to style these elements directly and overwrite them later, should there be a block with included lists in the content area.
In Gutenberg, I can now choose one of any number of list styles as the default and the customer can select any other of them at any time later.
The advantage here is that the customer / editor can see exactly which classes / styles are available for a specific block – but that is another topic
Yes, I can override all basic elements, but the big advantage with the technique I’m using is that I don’t have to look at which properties I have to overwrite. If I later change – for example – the padding or add a background-image to the base element, I have to remember to reset these properties in derived elements.
Another example (I normally using scss with “extend”):
Building up different kind of buttons as class styles without attaching them directly to an “button” element or an “input” element (submit) or an “anchor” or an “div”. I’m later completly free to add whatever style I want to whatever element I or the customer want.
I have to admit that it’s still hard for me to make sense of all the different “global” sections in Cwicly.
For me there are really only classes and custom properties or scss vars. These I apply as default or later where I need them, done. So now we have i.e. “global colors”, but why not just an section with “global variables” (custom properties)? So everyone would have the freedom to define in it what they want.
For me, a tool (like Cwicly or WordPress in general) should give me as much freedom as possible to implement my or the customer’s wishes.
So i.e., I have been using em/rem and classes for years, while others prefer to use pixels and / or style ids. I do not want to judge here and say that one is better or worse, each as he likes.
Yes, @Louis, overriding is simple, thats not the point. I’m sorry if it came across that way.
The key point and negative thing is the cascading of unwanted / unnecessary styles.
Example:
/* Defining a base list style */
ul {
list-style: outside none;
background: rgb(232, 232, 232);
padding: 0.5em 1em;
margin-bottom: 1.5em;
}
ul li {
font-size: 0.9em;
color: black;
margin-bottom: 0.25em;
}
/* Now defining a navigation block *inside* the content area, so the navigation block is affected by the base list styles above
I have now not only overriding old styles but also reset / unset previous ones */
nav ul {
list-style-type: none; /* overriding */
background: none; /* or "unset" */
padding: 0; /* or "unset" */
margin: 1.5em 0; /* overriding */
/* and additional styles */
}
nav ul li {
font-size: 1rem; /* or "unset" */
color: var(--base-text-color); /* or "unset" */
margin-bottom: 0.125em; /* overriding */
/* and additional styles */
}
Perhaps it is now clearer where problems can arise. Or how could I solve this in Cwicly with the current solutions?
Assigning a default class would avoid this problem, because you are not styling the element itself and all new styles for an element would be completely encapsulated in a new class.
For me, it seems like you are creating problems first on a general basis which you need to fix then on a regular individual basis.
Could you elaborate on why would you style the tags that way?
From my understanding, tags should carry bare/base styling only (if any).
And then, how everything is linked to block default classes?
I really have some issues to connect the dots here.
Just trying to understand your approach better to potentially give some advice how to utilize already in-built options in Cwicly.
I think you are forced to apply classes on blocks to change/reset styling which you attached on tag level.
That at least is my impression I initially had when I read your original post.
You also stated, that it’s a habit. Maybe you want to take into consideration getting rid of it.
Cwicly is built in a very logical and native way, so why not adapt to unfold its real power?
I understand that everyone has different workflows and approaches. But I feel it’s something which isn’t even Cwicly related.
Yes, I do think that I need to change the way I work in order to fully exploit the potential of Cwicly. Maybe I’ll just mix normal Gutenberg blocks for standard elements and use Cwicly for more complex layouts. That would be perhaps a solution for me.
But why, for example, is there a div wrapper around the list by default? It is a way to prevent the problem I described – to stop cascading. But you could do it without the div wrapper if all styles were only assigned to the ul element via a class. So my example above should just show why I’m using this technique in general.
My actual and initial problem and reason of the feature request, however, is how an editor can add a list, for example, that is already provided with a class that has all the necessary styles as standard - without always having to add a class manually or restyle the list itself.
Please also note again my example of the Gutenberg plugin, where you can apply a default class when adding a block (or then selecting another class style) – this is independent of my technical explanation or the type of implementation internally.
Perhaps you can give me a clue how to solve that problem in Cwicly.
Thanks for making things more clear to me @Jugibur.
I think I got a pretty good idea about your general idea behind it and some scenarios you want to cover.
The first thing which comes into my mind is the design library.
You have all freedom and flexibility to add whatever is required for your use cases.
Is there a reason why you didn’t consider this approach already? Seems to me like a perfect fit.
This way you can add all the classes which are required, you can even build various versions of your elements.
At the same time your basic blocks won’t get affected and remain their default style.
I think in the future you will be able to show only specific libraries (at least hide Cwicly’s and Community’s one) to specific user role or even individual users.
Maybe that’s something you are currently concerned about?
I agree, in general, the Design Libray is excellent for saving and discovering designs!
But especially for very simple elements, as mentioned lists or even buttons, I find a preselection of a style useful just to reduce mouse clicks, calling / loading the library and searching there for styles.
Surely it also depends on whether a design-intensive page is to be created, or rather a text-heavy one that normaly needs little mouse interaction in Gutenberg and you can concentrate fully on writing.
But let’s leave the discussion at that, I will just deal with Cwicly more intensively. And in fact it shouldn’t be a problem that I rather use the Gutenberg blocks for text-heavy pages, which I then configure for my customers in advance.
This is automatically set (to <a>) whenever you add a link to the button element (or any other linkable block in Cwicly). I take it you are specifying what your button is linking to in any case, or do you have a special technique for this?
Every Cwicly button has the class cc-btn added to it automatically, allowing you to target it specifically.
From there, you can go to Global Elements → <a> → specify cc-btn in the class window and have all your buttons on your installation share the same styles.
My thoughts here:
Concerning global style presets for Cwicly blocks : It is not about creating complex global styles, it is just to set some basics (like in Gutenberg) as paddings, margins, borders and background colors of blocks like columns, accordion etc… The advantage I see is not only that you start your site with sound settings you feel comfortable with, it is also, if you later want to change e.g. paddings in your grid, or more margin between your blocks, it’s one click to change and see how that looks like
