IMPLEMENTED: Remove Bricks selector from CSS output on custom classes so the class can be used on different elements

Not sure if this is a bug or a feature request :slightly_smiling_face:.

The CSS output includes a Bricks element class. If the same custom class is added to different elements an additional CSS declaration is output. This behavior of adding the element class to the custom class also makes it impossible to use these custom classes on non-Bricks Builder elements. For example, a WP Gridbuilder card or WS Form button.

I think the best solution is for the CSS output to only include the custom class name. This will allow using the custom class on other elements and will eliminate the duplicate CSS declaration when a custom class is used on different Bricks elements.

Here is a video recording demonstrating the issue: Unexpected Bricks Builder CSS Output Behavior - You Can't Use Custom Classes on Non-Bricks Elements - YouTube


I think you are misunderstanding the CSS that Bricks creates in the inline CSS

.my-custom-class.brxe-heading {color: var(–shade-medium)}
.my-custom-class.brxe-text-basic {color: var(–shade-medium)}

This is not two new css classes, this is one class applied to two different elements with different existing classes.

still bad, but it shouldn’t prevent you using my-custom-class elsewhere, that might be a different issue if you can’t.

1 Like

I do agree this needs to be changed as it bloats the CSS on sites and violates DRY standards.


Agreed. Single output of the custom class allows for needed flexibility and reduced bloat. Great catch here.


It is indeed very annoying. Why adding to the selector, the default bricks class for the current element? What were the reasons behind this @thomas?


I’m voting for this as well!

Further to this, these custom classes are added to a style block on every page that they are used, even if ‘external files’ is ticked.


@thomas @luistinygod @Sridhar

This needs to be changed asap, thanks


I noticed this some time ago. But I wasn’t aware it was unusual. I also second this. The classes shouldn’t stick to the default classes generated by the builder.


None of them should be sticking together.

As an example, I took this screenshot from Zion & LiveCanvas



As we can see that there wouldn’t have classes sticking together
Let’s say min-vh-90 wouldn’t stick with the container-fluid

Zion Builder

As we can see that the grid-2 is not sticking to the .zb-section__innerWrapper

Info above is just for reference.


Agree this is a must have!


This is must have fixed.

1 Like

Wow! Never seen so much response to a request in such a short time. I also request this to be fixed asap.


Fully support this request!

1 Like

Agree, this is an issue that must be addressed an fixed. +1 for this

1 Like

+1 to this request.
Wonder what was the initial idea doing it the way it behaves now.

Well does responding to this amount to a vote of support or is there something else one needs to do. I’m on mobile so maybe I’m missing it?

I agree. Would be nice if it’s done a bit cleaner. Just the class name that’s needed.

This is an issue that must be addressed and fixed. +1

Custom classes should be reusable and not chained like this. Unless there is some other “normal” way to do independent global custom classes?