NO BUG: Image Gallery Masonry Layout: No Top/Bottom Spacing

Browser: Chrome 110
OS: macOS

Updated a Site from 1.12.4 and on two Pages with Image Galleries in “Mansory Layout” there is no more horizontal Space. Vertical Space ist working fine.
Tried to change Layout to Grid and back, but the issue is still there.

Hi berndt,
Thanks so much for your report!

Please provide a live link and screenshots of your gallery settings.

Best regards,
timmse

Did disabling Autoptimize also solve this problem?

Unfortunately not. If You want to have a look, I’ll provide You a Screenshot an a link:

Deactivate JS optimizations if you have them enabled. Alternatively, try to exclude isotope.min.js / remove the defer attribute (I’m not sure if there are any options in autoptimize):

I’ve tried to exclude the “isotope.min.js” with Autooptimize, but this does’nt help. Unfortunately, deactivating “suspicious” plugins doesn’t help either (Autooptimize, Motion.Page, ACE, Cache Enabler, Bricksforge, etc.)

Please send temporary login credentials and a link to this thread to help@bricksbuilder.io using the email address you used during the purchase.

Hi Berndt,
Thanks for the login credentials!

ACSS is the culprit as it overrides the margins (red). I added a temporary “fix” to Bricks » Settings » Custom CSS (green - maybe there’s some setting in ACSS to exclude certain selector from the defaults):

You should report this to ACSS to get it sorted in the long run. As soon as they @layer their styles, there shouldn’t be any issue anymore.

1 Like

Thank You again! :wink:
I’ll report it to ACSS.

@timmse sorry, but this isn’t a bug on ACSS’s side.

It may be that ACSS is overriding the Bricks styling, but ACSS has a specificity of 0,0,1 and Bricks’s has a specificity of 0,3,1


The problem, however, is that you place the styling in the Bricks layer and not outside of the layers. This means that it can be immediately overwritten by virtually any plugin that styles the li tag, for example, with margin-block. The same applies, of course, if a user applies global styling like margin-block to the li. This is why ACSS overwrites it, even though it uses the smallest possible specificity. And placing ACSS in a layer below the Bricks layer would destroy the principle of a CSS framework.

You simply overwrite the variable located in the Bricks layer locally on the class or ID in the Bricks gallery element.

Such things shouldn’t be in the layer if they’re intended to be overwritten/restyled.

This is a Bricks (CSS layer) problem, not an ACSS issue.

Hi @tobiashaas,

As you probably know, in the layered cascade specificity only matters within the same layer. A selector with a specificity of 0,0,1 in the default (unlayered) layer will override a selector with 0,3,1 inside a named layer (like the bricks layer), because unlayered styles sit above named layers in the cascade hierarchy. So bringing up specificity here is irrelevant.

That’s not a problem. That’s exactly what cascade layers are for. Bricks puts its default styles in a named layer (bricks) so they can be cleanly overridden by user styles or utility frameworks like ACSS.

That statement contradicts how cascade layers are meant to be used. The entire point of placing default styles in a lower-priority layer is to make them easy to override.

I don’t really see how this is a Bricks issue. If your styles previously expected Bricks to “win” in certain cases, that assumption no longer holds. Your selectors may need scoping adjustments, or you may look into moving the ACSS styles inside the bricks cascade layer. The former is probably easier to test for.

TLDR: Bricks moved default styles into a layer. If that breaks existing assumptions in your CSS, it just means you need to adapt to the updated cascade model (which was first introduced in v1.12).

That statement contradicts how cascade layers are meant to be used. The entire point of placing default styles in a lower-priority layer is to make them easy to override .
If you define styles in the Bricks UI, they shouldn’t be in the layer because they shouldn’t be overwritten.

The layer should only contain resets and defaults, such as brxe max-width: 100%, but not styles that are changed/adjusted in the Bricks UI.

Why does this styling for example have to be in the layer?

Independent of ACSS. The class name .sticky is far too general. Any user could create a .sticky class and thus override this styling in the header, right?

And the same goes for the Masonry Gallery.
The only thing outside the layer is the variable “var(–gutter)” which overwrites the value in the Layer.

Regardless of whether it’s set to the ID or the class in the Bricks UI. It’s only overwritten as a local variable, but that doesn’t prevent this styling from being overwritten by another stylesheet.

@charaf what would you suggest to fix it?
Should we add ACSS also to the layer, or how would the Bricks team proceed?

I’m trying to resolve the issue so I can talk to Kevin.