Class System

@Louis - In the live Stream you explained the current class system as:

1-Block specific class that holds the styles applied to that block
2-Additional classes that you can’t change in the Gutenberg block options panel (maybe from your external style sheet)
3-Global classes that you only change in the global panel

That makes sense. Thank you for explaining it.

One thing that seems odd to me is that normally with CSS you use ID for individual element styles. So individual block classes seems counter to usual CSS principles. Also, I guess the idea was I style a button on page one (#1 block specific) and like it so since it is a class I can use it on page two. But since the class names are randomly generated its hard to track that first class to reuse it.

So wouldn’t it make sense to me if:

1-Block specific styles would be applied to the block ID (and only loaded per the page)
2-Additional classes that you can’t change in the Gutenberg block options panel
3-Global classes that you only change in the global panel

In that view I would think you would use #2 additional classes to add utility classes from a CSS framework. Also, your comment about being able to have an external style sheet open in a floating panel seems like it would make #2 easier to use. Also, using WPCodeBox or Scripts Organizer where you have live refresh when you make an external change would make #2 easy to use also.

1 Like

@David CSS can be applied to HTML elements (div, p, ul, etc…), ID’s (#id), and classes (.class), so you’re right, CSS can be applied to ID’s. I think it’s more of a best practice to avoid being over specific in CSS. ID’s have a very high specificity, so a class can’t override an ID without adding !important. Adding !important is a bad habit to get into, so adding CSS to classes keeps things a bit cleaner and makes the CSS reusable in different areas. This is an oversimplification, but that’s kind of the idea. The highest specificity, I think, is adding inline styles directly into your HTML tag, which is not really a best practice these days either. It all technically works, but you can run into trouble (specificity wars) when you’re having to increase specificity more and more to override things.

So, the class field is basically applying a class to a block, where the CSS is tied to that block (similar to an ID, but less specific). You can apply that same class elsewhere, but it’s still tied to block it was created with. It’s similar to if you tried adding custom CSS to the Custom CSS section of a block. It’s tied to that block, so if the block gets deleted, so do the custom CSS properties.

I think Cwicly does this right because you can have your specific block class styling, additional classes for use when you create a custom class in the stylesheet (or pull in classes from a framework), and global classes, which are similar to “additional classes”, only you’re able to style them directly in the visual editor.

@Louis I don’t think you necessarily need to change anything, but making the documentation clear on exactly how things work, with examples (like the Tailwind documentation), would be best. I’ve been following along with the Bricks development, but it’s honestly turned into a circus in my opinion. Too many people trying to turn Bricks into Oxygen or Elementor, and too many people who don’t really understand how HTML, CSS, and JS work trying to make the builder do things that are way overkill.

Case in point is the new Bricks Section, Div, and Block elements… Before, they had a wonderful “Container” block that could be any of those things, but people didn’t understand how it was supposed to work, so now they have 4 blocks, when all you really needed was the one. It was a case where I think the effort could have been better spent educating the users on how things are supposed to work.

I think with Cwicly, as in life, @Louis, you should stay true to your vision. Try documenting things clearly so it’s easy for people to look up exactly how something’s supposed to work. Don’t go down the rabbit hole of trying to make everyone happy or you’ll end up with a Frankenstein product that you will not longer enjoy working on. I appreciate the way you think and how you create the minimum pieces to get the most things done. People are used to page builders and don’t like Gutenburg, but that will change more and more as time goes on. People are already making the switch to Gutenburg because it’s where WP is going. Some people just get stuck in their ways and don’t want to change, but if you keep moving with your vision, the day will come when people will start realizing that page builders are kind of old fashioned.

I could feel your frustration in the live stream today and I feel the same way when people, who really don’t have a clue, are essentially shaping the future of other tools like Bricks. Oxygen was almost the opposite where they didn’t really listen to what people wanted and did it their way. Obviously they listened some, but they made it the way they wanted. Apple does the same thing. A good product will be used by the right people. It’s probably easier to support a product when most of the users are half way saavy anyway, and not when you have a bunch of people who don’t really understand how to build a website.

Anyway, sorry @David for hijacking your thread, but I wanted to also help clarify things and let @Louis know that he doesn’t have to turn Cwicly into a monster just to try to please the people who really don’t understand in the first place. Build a product for people who “get it” and fill that niche that Oxygen is losing and then look for ways to maybe simplify and refine things over time. These are just my thoughts, but look at GeneratePress too, that guy doesn’t add anything that he doesn’t want to have to support later.

To sum up, haha, don’t lose your vision because you CAN’T make everyone happy. Keep things as minimal, simple, and clean as possible, with really good documentation, and the right people will figure it out and use it. Everyone else will be playing in the circus of madness over at Bricks, Breakdance, and wherever. Too many cooks in the kitchen is never a good thing!


Thank you so much @msguerra74 :pray:

Please don’t throw your initial vision right out the window @Louis, try to give everyone a better understanding.

I feel like people doesn’t know which opportunity they are missing and it really makes me thinking.

I didn’t participate in the live stream class system discussion and I won’t say anything related here. Just kind of tired.
What I will do now is to mute this thread.
Hopefully, this doesn’t get out of hand.



@msguerra74 I think the Bricks newer approach is more solid when combined with the theme styles.

I was using container with flex stretched before for full width which I don’t need to as a section is 100% width by default.

You can apply comfortable padding/margin or other display options to block, container and div element. I have padding left-right for the container for example. I use block when I need flex but no padding. I use div when I need an unstyled element.

It was possible previously but with 1 more click. When grid comes in Bricks - I’ll modify one element to grid related styling in theme style.

I was against the idea initially but I got used to it more as I used it.

1 Like

@msguerra74 I completely agree with you and hope @Louis will stay true to his vision because his vision seems perfect to me. I think Cwicly is already amazing and will get better with each release. Yes, it is more advanced and seems more complex from the first look, but it gives me freedom and output that no other builder can. So hope it mostly stays the same and good documentation might clear things up for everyone.

Regarding the class system, I understand it, I like it, and I have no problems using it. My workflow usually is to use global classes as much as possible ( to avoid duplicate styles) and only then blocks specific styling if needed.
I have only a few things to mention regarding class system:

  1. I would like to have an ability to remove auto-generated ids and classes and use them only when needed for block-specific styling or interaction. This would make html even cleaner. Could be option to use them or not according to user preference. But seems it is a planned feature already.

  2. For even better performance I wish block-specific styles were loaded only per page base in order to keep generated CSS stylesheet light. Currently, if I have 10 pages and all of them have some heavy block-specific styles applied, then “cc-main.css” stylesheet can get pretty huge. It includes all classes and styles applied from all 10 pages. Not a big a problem for me because, as I mentioned, I use global classes as much as possible to avoid duplicate styles, and barely touch block-specific styling. So this keeps my “cc-main.css” stylesheet clean and light. But for someone who is not so skilled (maybe client, end-user) obvious and easiest choice is to use block-specific styles. By doing so for every block, you get a lot repeated styling, and “cc-main.css” stylesheet can get pretty huge. To somehow limit this is, a good solution would be to load only block-specific styles per page base, meaning that “cc-main.css” stylesheet doesn’t include styling from all 10 pages but only for 1 page. And if there is an element that needs sharing style between pages, just use global classes or styling.


Yep, I’m fine with refining and streamlining things, and I agree, these both sound like good ideas. The additional classes list can get a bit messy because it includes all of the generated block classes even if they’re not used. I understand why they’re there, along with the IDs, but I would prefer to add them only when needed (classes for styling and IDs for JS/interactions).

Maybe an option could be that, by default, there are no classes or IDs, but the moment you add any styling or interactions, it generates a class and/or ID if one doesn’t already exist. I’m sure @Louis will come up with a brilliant solution no matter what.

Definitely a per page stylesheet could be nice to eliminate loading unnecessary styles, but I’m less concerned with this because once the styles are loaded they’re cached, where a per page stylesheet requires a new load per page. For most of CSS’s history, we’ve generally put everything in one stylesheet and that’s worked fine, so long as it’s as lean as possible. So not creating extra classes and IDs automatically should clean up the stylesheets pretty drastically I would think (if empty ones are even added to the stylesheet, which I’m not sure).

Thank you @David for starting this thread and thank you @all for taking the time to share your thoughts.
Really helpful to me and the team.

Thank you @msguerra74 for sharing your invaluable thoughts.
This comforts me to see that what we have done with the class system does have something to stand on.
While explaining the reasoning behind it in the live yesterday, I was reminded that while it definitely does need consolidation (whether it be visually or logically), it is something that I am quite attached to.

We also received quite a few messages after the live from users saying how beneficial this class system has been for their workflow, and that they have happily adapted to it.

I don’t think we will ever move default block styling to block IDs. The specificity implied with the ID is just too much of a trouble-causer to really be considered.
BUT, I do think the possibility should be provided by Cwicly to style the block ID independently from the Class.

@krievinshj, the per page stylesheet is in my opinion a double-edged sword, as @msguerra74 said:

We’re told to focus on that first load, but we do forget that a website isn’t limited to a single page, and that the experience after the first load is as important.
This is why we went down the road of having a single stylesheet for an installation.
At the same time, I have recently seen some stylesheets from Cwicly users that could be considered far too big… And this is where a per page stylesheet might have its advantages.

I’d love to hear more of everyone’s thoughts on a per-page stylesheet for block specific styles, as this is something I am currently hesitating about.

Finally, we are going to have most of the Cwicly defaults (relative position, flex etc…) removed from Cwicly blocks.
There will be a temporary/permanent option to keep them so that we don’t have any breaking changes in styling.
This will automatically allow us to remove classes from blocks that don’t have styles, which will already sooth stylesheet and dom sizes.

This will also lead the way to user set defaults for blocks.


Thanks @Louis. I honestly don’t care if the styles get loaded per page or all at once, but maybe your idea of placing the block-specific styles per page would be a good compromise. Then all other styles can load in a single stylesheet globally. I would imagine the bloated stylesheets come from block-specific styling anyway, since global styles are single classes.

I’m very excited for being able to set block defaults to better fit our own habits and/or frameworks. I really think the out-of-the-box defaults, if they’re going to exist, should be based on CSS defaults. Flex blocks are a good example because they default to row, which is the CSS spec, but the majority of my use is with columns, so being able to set that default would be a time saver. For now, I have a section class that uses relative styling to set things they way I like.

Cwicly resonates with me so well and it’s the product I would build if I was as talented as you. It’s because of this that I don’t want to see the community become a circus like some of the other ones and see a very well thought out product turn into a mess. I understand you want to reach the widest market and I trust you’ll do what you think is best, but I really think you should continue taking community feedback and putting that amazing Cwicly spin on it. People will complain and then they get over it, so unless it’s a situation where the majority of the community thinks it’s a bad idea, then I would just do my best to educate them via YouTube and documentation.


Thanks, @Louis . Can’t wait for block defaults because find myself removing relative position, flex, etc. from block styling all the time.

Regarding single stylesheet :

And I probably know why.
I did a small experiment with my friend who is considerably less experienced in front-end editing than myself, with Elementor and Divi background, looking to get his hands on Gutenberg, a potential Cwicly user. I offered him to try Cwicly to build a small landing page with 5 sections, title, text, and a button inside each section evenly spaced and centered. Pretty simple!
His workflow was as follows: he styled the section and everything inside it using block styling options and then just duplicated it 4 times to have 5 sections. Done. Easy! He was pretty happy with the result and Cwicly itself. I assume an average Cwicly user would choose the exact same workflow.

On the other hand, I did the same landing page with one global class for section and relative styling attached to it to target child elements. Then duplicated it 4 times. So as the result I ended up with a stylesheet 5x smaller than his because his stylesheet included similar styling but repeated 5 times for each section. Imagine if there is some complex landing page and 30 or more of them and done in the same way my friend did! So you get the idea of where those big stylesheets coming from!

Cwicly is a really powerful tool and in hands of someone skilled, it might output the best code out there but in hands of an average Elementor user who might go crazy with the block styling options, the stylesheet definitely will get bigger with each page created. And then everyone wants those perfect scores on Google pagespeed insights but in this case, all they are going to see are average scores with big render-blocking stylesheet warning.

That is why I think the problem with big stylesheets needs to be addressed somehow. I am not skilled enough to come up with some really smart solutions besides my suggested page-based stylesheet but wondering how other builders do this!? I know GenerateBlocks use per-page stylesheets, not sure how they handle caching part but performance wise it is really good.

1 Like

Hi @krievinshj,

Thanks for sharing this little piece about your friend’s experience, which fits the narrative and the dangers of a global stylesheet for all blocks. The points you’re making are spot on!

I think this is the good moment to start moving all block classes to their specific page only, which will alleviate both the backend and frontend.


@msguerra74 - I understand what you are saying and I’m fine with using classes, but I am not sure whose ID styles you’re overriding? It seems like if styles set in the Gutenberg editor are assigned to the ID then there is no overriding of them needed as you just go and make the setting change. What am I missing?

One point about a single style sheet vs per page style sheets - my understanding is that back when the recommendation was for a single style sheet but now it is to put page specific CSS in a per page style sheet. The reason is that now browsers can download multiple files at the same time.

@David Sorry, I was just talking about IDs in general, not specifically within Cwicly. More as a possible reason as to why they may have chosen to go the route of tying styles to classes rather than IDs.

You’ve always been able to attach multiple stylesheets per page, so it was more about server requests. What’s faster, pulling down a single 100k file or five 20k files. I’m sure it’s negligible either way, but it was a subject of debate once upon a time.

I’m pretty sure it was your first video about Cwicly that got me started with Cwicly, so thank you for that!

Hi @Louis,

Is there any update on this?

I’m using more and more virtual classes, which I love, so I’m also more and more confronted to this conflict issue:

Adding ID styling would solve a lot of specificity problems and would be so more respectful of CSS power.
(It is also more intuitive to me for individual/unique elements, but the virtual class is so powerful, I understand that systematically using IDs would void the whole concept!).

Regarding UI, maybe transforming the inspector ID/class labels in toggle buttons would avoid adding bloat to the panel?