Hi!
This was actually the issue before Beta.
Background color of containers is normally below both Upper and the Lower background layer. However that is not the case with CSS Grid Cells: background color is covering the background layers.
Thanks!
Thanks Misho! We’ll check it out. Sorry for the delay here.
1 Like
Howdy, @Misho!
Thanks for writing in! So there isn’t anything actually “broken” here; rather, it’s a matter of the defaults used on these Elements that we eventually wanted to apply everywhere.
So the way that the advanced backgrounds work is that they’re physical markup output to the Element they’re in, and they have a z-index of -1 to force it behind all content and not obfuscate clicks on interactive elements like buttons, or prevent users from copying text, et cetera. Using z-index: -1; will cause the markup to go behind the parent Element unless a z-index of an integer is set on the parent Element itself. Effectively, if you’re using advanced backgrounds, the parent Element must have anything other than z-index: auto set.
All of our layout Elements up until this point have had a default z-index of 1, which we set this way for the purpose of avoiding this issue with the advanced backgrounds and not having users need to set it; however, this can create other layout issues on a more macro level, so we’ve been wanting to move away from this default for some time.
With the Grid and Cell Elements, we set their default z-index to auto, which allows then to natively stack more appropriately in the browser, but this means that if you turn on an advanced background, you must also set an integer value for the z-index input on it.
After chatting with Alex, one thing we’re going to explore is setting all layout z-index settings to auto and introduce a script that effectively does something like the following:
- If a user turns on an advanced background and the
z-indexof the parent isauto, update thez-indexof the parent to1. - If a user turns on an advanced background and the
z-indexof the parent is an integer, do not alter this value as it has already been set by the user.
We have a few things to chew on here, but we’re going to look into this and see if we can get this all mapped in at some point before the official release. For now, you can set a z-index value of 1 or above on your Grid / Cell and your advanced backgrounds should appear as you expect.
1 Like
Thank you @kory for such a detailed answer!
I set the background color to all elements that have text color which would otherwise have low contrast with the site background color. This is needed to maintain contrast until the picture is loaded.
However, that is mostly needed on top level containers like a sections. Having an option to place the background color to the foreground is a nice touch, because it lessens the need for situations like when we want a cover layer on interactions, like what we can see with grid plugins. So this is fantastic! It wasn’t immediately obvious, so I appreciate the detailed answer.
It would be great if native effects could handle such interactions, but a bit custom CSS is fine as well. 
Thanks!
FYI, I was switching back and forth with the page that has CSS grid (Beta 5), changing the z-index, effects and stuff. Suddenly the entire page got frozen. I had to reload it. I have tried to reproduce the problem but I cannot anymore.
No problem, @Misho! Always happy to help shed some extra light on things. Could you elaborate a little more on the situation you described above with the text color and all that? I think I’m following, but perhaps if I saw a working example I could see what you’re discussing and see if it’s something that might be able to be easily integreted in.
As for the freezing, that’s very odd. I haven’t experienced any of that in this entire cycle, but if you run into it again, try inspecting the page with your dev tools and look to your JavaScript console for any errors and feel free to share them with us. Better yet, if you’re able to deduce some sort of pattern that is causing it, a video is always the most helpful to see things live.
Thanks!
1 Like
Hi Kory!
Sorry for my messy reply. I was a bit in a hurry. So the dark background color always needs to be set below the image if the text is light, despite the fact that this color cannot be seen. The reason is because the light text cannot be seen if the image is mission or slowly loaded. This is one of the most common mistakes done on the large hero images.
The fact that the background color can be set to the front of the upper and the lower image/color is nice, because we can add cover interactions to it with CSS. This is very common with grid plugins.
Hi Kory!
I’m so sorry fore being so confusing in this thread. 
I’m not after anything here. I was just expressing how great the new system with the z-index is. I was also saying that my preference is to always set the background color, even when it is not visible due to the background image. The reason is because it takes care of the contrast in case the background image doesn’t load. No further actions on this is needed from you guys.
I also like that the new z-index system is able to set the background color above the background images. This is because then I guess I can animate it with custom hover CSS, similar to what I have done with one of the background colors: .container-custom-class:hover .x-bg-layer-upper-color This will leave two background colors plus the “Cover” color on a clickable container.
This effect can be seen here: https://www.mojemalozlato.com/en/, on the Grid cells. (Though, I do need fix the text contrast there).
Thanks!
No worries, @Misho! I just wanted to make sure I was understanding anything you were trying to convey. Thanks!
Update: In beta7 all layout elements have z-index: auto by default. This is ideal because you really shouldn’t declare a z-index unless you really need it. If you enable Advanced Backgrounds the z-index will automatically be set to 1 since it is required. This feels like the best approach moving forward to reduce the likelihood of encountering this issue.
1 Like