Transform and z-index stacking context

[friendlygiraffe 11 Likes (Newbie)]

Might not be specific to GSAP, but:

 

You'll notice when the button is clicked and the function is fired, it seems to remove it's functionally. See in example

 

Thanks

See the Pen JOwZjb by friendlygiraffe (@friendlygiraffe) on CodePen

Edited December 1, 2017 by friendlygiraffe
Wasn't a Z-Index problem

[Sahil 2,541 Likes (Superhero)]

No it doesn't remove z-index. You can check console in demo. You are probably looking at element with id 'background_exit' that covers the button.

 

See the Pen dZwqby by Sahil89 (@Sahil89) on CodePen

 

[friendlygiraffe 11 Likes (Newbie)]

4 minutes ago, Sahil said:

No it doesn't remove z-index. You can check console in demo. You are probably looking at element with id 'background_exit' that covers the button.

 

See the Pen dZwqby by Sahil89 (@Sahil89) on CodePen

 

Thanks, any clue why is the button no longer clickable ? 

[Sahil 2,541 Likes (Superhero)]

I googled it and found out what could be happening but @Jonathan or someone else can explain it more accurately. When you use transform on element,  a new stacking order is created for it. As you are transforming parent which doesn't have z-index of it's own, a new stacking order for it and it's child elements is created. As a result, the child element with z-index remains below the 'background_exit' because it is in different stacking order. You can fix it by setting z-index of parent to 1. (Which I guess brings it in normal stacking order)

[friendlygiraffe 11 Likes (Newbie)]

It seems to work when specifying #background_exit as z-index:-1;

 

Would be good to find a more flexible fix though 

 

See the Pen jaXpYm by friendlygiraffe (@friendlygiraffe) on CodePen

 

[OSUblake 9,990 Likes (Superhero)]

Had you gone to jQuery plugin school, you would know that setting the z-index to 9999 is the best way to make sure your content stays on top of everything else. If that doesn't work, try 99999. And if that doesn't work, just keep tacking on another 9 until it works. You'll eventually find that sweet spot, and land on a number that is large enough to put it on top. 

 

Don't actually do that. There is no need for a number that high. The z-index value only applies to the stacking context an element is in, so think of it as a local or relative value. It's sandboxed.

 

If you're doing animations, there's a good chance you're creating stacking contexts. Figuring out what stacking context an element belongs to might require a little work. You have to walk up its tree and find the first element that matches one of the scenarios found here.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

 

Or you could use the Layers tool in Chrome / Opera. It will show you the reason a stacking context was created for an element.

 

 

But what is a stacking context? A lot of people seem to be confused by the concept, and that's because they are looking at it from a CSS perspective. It's really not a feature of CSS. It's related to rendering. Think of a stacking context like a layer in a traditional cel animation. What gets rendered to the screen is a composite of all these layers stacked on top of each other. 

 

 

 

 

These layers (stacking contexts) are used to improve performance (transforms, will-change) or to correctly render stuff that has to be drawn in multiple steps/passes (opacity, filters). If you've ever used canvas and had to draw something to an offscreen canvas, a stacking context should make a lot sense because it's the exact same thing. 

 

Knowing that the browser draws stuff on different layers, you should be able to see why an element's z-index is limited to the layer it's drawn on. How do you make an element drawn on one layer appear over an element drawn on a layer above it? You can't.

 

If you want to learn more about rendering, @Carl sent me a really great article. It's about how a new renderer coming to Firefox is going to work like a 3D game engine. It's a really interesting read, and does an excellent job explaining the whole rendering process, so it goes over stacking contexts. 

 

https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/

 

 

[Jonathan 5,176 Likes (Superhero)]

Hello @friendlygiraffe

 

This issue is more of a CSS rendering issue than a GSAP issue.

 

The reason you are dealing with this is basically CSS. Since you decide to use position offsets like position absolute. Then as a rule of thumb you should always set a default z-index on elements with position absolute and fixed. Most rendering issues have to due with missing CSS properties or wrong use of CSS properties! Even though z-index is a CSS thing, CSS is what drives rendering. And even though this is a stacking context issue, it is fixed by z-index on the right element. Since stacking context is dictated by the CSS used on the page, and that is why CSS affects stacking context. That is why the fixes and what defines a stacking context, is CSS

 

That is why when you added the z-index:1 to #background_exit, it solved your issue. You not only are using position absolute, but also a transform on that same element. So that means the element will have a new stacking context regardless of z depth which is what z-index is.

 

You either have to use the z-index:1 or give that same element a new stacking context with a simple CSS of translateZ(0px) and that will solve your issue as well. 

 

More about stacking context here.

 

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

 

About z-index:

 

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/Adding_z-index

 

Also make sure that anytime you use position offsets like fixed or absolute, you must also have a parent that has position relative to make sure your elements are positioned the same cross browser. Without position relative the browser wont have that reference point, and then you will get different rendering behavior. This way your absolutely positioned elements are positioned relative to their parent. Never trust the body element as your main relative element for position offsets, otherwise be prepared for bug city cross browser.

 

And this also could have been resolved by changing the order of your HTML markup.

 

Happy Tweening

[Carl 9,066 Likes (Superhero)]

[OSUblake 9,990 Likes (Superhero)]

I can't stop laughing!

 

That is getting framed and going up on my wall today. My mom is going to be so proud of me. I knew all my hard work would eventually payoff.

[Jonathan 5,176 Likes (Superhero)]

@OSUblake thanks for sharing!

 

I like that article from Mozilla on The whole web at maximum FPS: How WebRender gets rid of jank. But she is wrong to think that a flip book would require 60 pages for each second, since traditional animation flip books by trade use 24fps or 30fps (29.97fps). Mostly a rough flip book can use 10-15 pages per second (fps) and still look silky smooth. But i understand her comparison with web 60fps, great article though

 

That's pretty funny about z-index. I hate it when z-index is misused and abused like that