Base classes for each block?

Feedback
1

Just thinking out loud here.

Removing the block defaults in v1.2 was a big step forward. The styling was always tied to the block specific class (ex. div-c4c1c4a), so this made the styling hard to override due to specificity and of course added unnecessary bloat to your stylesheet.

I think base styling via broad classes can be quite helpful in speeding up your workflow though. We now see this with image elements that automatically have the class .cc-img applied and have this styling:

.cc-img {
height: auto;
max-width: 100%;
vertical-align: middle;

It might be a good idea to expand this out to other elements as well.

For example, for most my divs I’ll generally want to use display: flex and align-items: flex-start.

I don’t think Cwicly should necessarily add that base styling, but it’d be nice if there was an easy way for me to add it.

Divs currently only have a specific ID and class (ex. <div id="div-cc9b376" class="div-cfe80e6">).

If they had the base class .cc-div, it’d be a lot easier for me to add my own styling.

I know I could currently use something like div[class*=“div-”] to target all of Cwicly’s div elements, but when unused block-specific IDs and classes are removed in a future update that will no longer work.

I could also add my own global class, but it’d be nice not to have to apply it to my divs every single time.

I took a look at Bricks, and they have a base class for every element as well:

image
image748Ă—190 32.4 KB

Thoughts?

1 Like
2

I had the exact same thoughts but had one doubt.
Only the classes which I actually use should appear in my HTML.
If this is possible somehow, it’s a clear yes from my side.
I just don’t want to bloat my DOM with something unnecessary.

1 Like
3

That would be cool. Maybe you could have a Block Defaults section under Global Styles for every block type. Then if you set a style, the base class shows up on the front-end.

Regardless, I would also definitely be fine with one class per block like in that Bricks screenshot if it meant I could set base styles.

1 Like
4

How about the opportunity to add default global classes to blocks?
Every time you add a block, this specific class is automatically attached to your block (appears under the class field as global class).
You would still be able to remove it, so you wouldn’t even need to override it.

Not sure if I made it clear, but I suggested it a couple of days ago.

Not sure, but maybe we’re sitting in the same boat already.

4 Likes
5

That’s a pretty good idea as well.

Only issue I can think of: what happens to existing blocks when you add a new default class?

6

Well, this could be discussed.

Default option should prevent design breaking behavior which means that the class(es) needs to be added manually afterwards to blocks that already exists.

But there could be an option as well to add a class or classes to all blocks of a specific type, which would even open more possibilities than the actual intended one.

These classes could be placed inside the global styles stylesheet, so they can be overridden at any time, also with any other global class.

2 Likes
7

I’m a bit late here, but what you all are suggesting would be best done with a saved design library component. Example, I create my own sections using divs, for more control. It’s the same from site to site, so I just save a component with everything I need.

What I definitely don’t want, are more defaults I need to override.

8

The new design library brought a new perspective to quite a few topics.

In addition, this idea isn’t about predefined values, defaults or anything, the idea behind was to have full control and assign whatever is needed for individual use, totally independent from other users or the way how Cwicly works in general.

And no, the Cwicly collection wasn’t an alternative back then, because it became unusable in an instant, as soon as the amount of items started to grow.

The section block has received some improvements, not sure if you are aware of it.
For my use cases, it’s now a solid block which became actually useful.

9

Haven’t checked out the section block, but will do so now. The inability to apply global classes to the inner container was/is a dealbreaker. I have utility classes that I add on a case-by-case basis, so without full control over this element, it just isn’t worth the headache.

10

Yes, that’s still the case.

Maybe you have something to add here, helping to improve things: