SOLVED IN 1.4: Container overlays are broken

Bricks Version: 1.4RC2

Hi,
Since 1.4RC2, container overlays don’t work anymore because background-color is applied to element instead of ::after.
(There’s actually no ::after created.)

Verified with root and non root containers, with class and ID.

image

1 Like

Hi Yan,
can you explain the problem briefly but in detail in the form of a video?

As far as I can see, overlays work for me as they should - but maybe I’m misunderstanding the report :v:

Best regards,
timmse

Sorry can’t make a video right now but the problem is simple.

You seem to use background-image property for BOTH gradient background and overlay:

So it is working when section background image is defined via with CSS background-image.

But…

ISSUE 1: There’s no difference between background and overlay settings… Or maybe I’m missing something, or maybe “overlay” setting only works for images?

image

ISSUE 2: I never use CSS background-image property because it’s not responsive and hard to lazyload, so I use absolute positionned images instead.
In this case, background-image overlay doesn’t work, since it affects the section bg and my image will be over it.
A real overlay is actually a ::before or ::after with background (color or whatever). So it can override anything with correct z-index. And we can use CSS blend mode, filters, etc.

So in the end maybe the “overlay” setting can only be used on images (adding ::after on their container) and “background” setting on containers adding gradient to CSS background-image?

This is not clear in the current UI. Maybe you should just reduce to only one setting called overlay, and do the right stuff accordingly to the element.

NOTE: The thing is I’m pretty sure it was working in 1.4RC, but can’t guarantee it :wink:

NOTE 2: Tried both settings on images and headings, still same effect, so what’s the difference???

@timmse, another issue with this is that we can’t add overlay to background video, which is a serious problem.

Correct. Prior to RC2 we had the overlay/background set on ::before with a z-index. So the overlay differed from the “background” gradient in that regard. We should probably remove the “Background” option from the dropdown to avoid any confusion. As it’s really only an overlay or a text gradient.

Relying on the ::before for the overlay caused issues for users who want to use pseudo classes on that same element. That’s why the gradient overlay is now merged with the background-image on the element root (as shown in your first screenshot).

If you use Bricks’ built-in lazy load, background-images are lazy loaded automatically :wink:

The issue you described I can’t reproduce, though. But maybe I misunderstood something. Let’s see …

If I add an image to acontainer (position: absolute, object-fit: cover; width & height 100%), and add a gradient under the “Style” tab it shows as the section background images as I’d expect:

Yes, overlay works on image, so I can use this; I was talking about container overlay over absolute image in ISSUE 2.

But there are actually different possibilities for overlays, so I agree with you, it’s OK to get rid of ::before ::after technics to let people use them as they want.

Here are the two technics I generally use, each one serving specific needs:

Overlay 1: Root container stretched (thus, no padding), inner container full width full height with background color and opacity (inner container bg acts as the overlay), add content in it.

  • Simple!
  • No max width because the overlay has to extend. So you need a additionnal container if you want to limit width, or change container padding, or max width on actual content elements (be it heading, text, container…).
  • Opacity and blend mode will affect content elements (nice effects!).

Overlay 2: Root container stretched, ABSOLUTE container full width full height with background color and opacity (whole div acts as overlay), then add the standard inner container (will be above overlay because inserted after, so no need to z-index).

  • Keeps inner container max width.
  • Opacity and blend mode won’t affect content elements.
  • One more div, but well… not more than additional ::after :wink:

Both work with section bg image or absolute image (inserted before containers) :slight_smile: