Jump to content


Transform and z-index stacking context

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

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



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

Edited by friendlygiraffe
Wasn't a Z-Index problem
Link to comment
Share on other sites

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


  • Like 1
Link to comment
Share on other sites

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 ? 

Link to comment
Share on other sites

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)

  • Like 4
Link to comment
Share on other sites

  • Sahil changed the title to Transform and z-index stacking context

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.



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. 





  • Like 6
Link to comment
Share on other sites

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.




About 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 :)

  • Like 6
Link to comment
Share on other sites

:lol: 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.

  • Haha 4
Link to comment
Share on other sites

@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 :)

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.