Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Mr Pablo

Stack ordering issue

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

I have come across this stack ordering issue when playing my GSAP based animations on a webOS TV (runs HTML5 apps using a webkit based browser)

 

My animations are made from various assets (images and text) and they all have simple A to B transitions.

 

Some assets might not move e.g. a background image, so despite having two transitions, the values will be the same EXCEPT they might have a tween duration (this is due to how the animations are created procedurally)

 

Now, if I have an image, and it doesn't move, and I have other animated assets, the "non-moving" image will shift its stacking order.

 

Stacking order is explained here: http://philipwalton.com/articles/what-no-one-told-you-about-z-index/, but I can't wrap my head around it to be honest.

 

It seems the combination of positioning assets absolutely (so they can animate properly) and having a tween duration for an asset that doesn't actually transition, causes it to "pop" in front of the other assets on each tween.

 

can fix it by removing the tween duration for any asset that doesn't move, but I have a lot of pre-existing animations I need to fix.

 

I'm hoping there might be something in GSAP or CSS that can be applied to fix this.

 

Unfortunately, this is only apparent on webOS so far, and I doubt anyone else here has a webOS signage screen to test this on :/

Link to comment
Share on other sites

Hello Mr Pablo,

 

It is really hard to give advice without seeing a codepen example so we see your code in context and in a live testable environment.

 

You can learn more about z-index which is considered z-depth for positioned elements with absolute, relative, or fixed position. Versus the stacking context of elements when they are rendered on a new layer using CSS transforms and opacity.

Once you have an understanding of z-index and how to position your elements within a parent using z-index. Then managing your elements become easy.

 

Just some simple rules to follow.

  • Do not nest multiple elements with z-index. Since z-index is only relative to its parent and not relative outside its parent or to one of its grandchildren in the DOM.
  • Always use position relative on the parent element, and use position absolute on your child elements. This way your absolutely positioned elements are always relative to its parent, that have position relative.
  • Keep in mind that when you use transforms on child elements, that will give them a new stacking context where z-index might not work. Since transformed elements get placed on there own rendering layer. That is separate from z-index.

I would go over those links above and first get comfortable with positioning elements. It is best practice to first use the CSS in your style-sheet to setup your scene. Like using the CSS position property along with top, right, bottom, or left CSS properties. Getting your elements in the DOM setup correctly in their initial state. And then use CSS transforms with GSAP to animate your scene. If you do that, and spend the time to setup your scene, then animating becomes easy and fun!

 

:)

  • Like 2
Link to comment
Share on other sites

As mentioned, the big issue here is that I could give you a CodePen, but the issue is only visible when running it on a webOS TV (Currently a specialised signage screen).

 

Either way, if I have a "master" DIV that contains my animated assets, if I give them a Z-Index, this is negated, as you stated above, transforms on a child element give them a new stacking context.

 

So how do I go about fixing the stacking context?

 

I want my assets in a particular order (typically, the first child is the bottom most asset) but if this stacking context is simply going to say "sod you, i'll put assets on whatever layer I want" how can this be solved?

Link to comment
Share on other sites

Like i said above.. we really can't help without seeing the issue! Since the stacking order and context can get complicated. And there are 100 different possible issues that could be causing it. So without seeing any HTML, CSS, GSAP code, and a live example. I don't see how we can help you with no context and no code. It would be like shooting blind. Its hard to help and fix an issue without first seeing the problem, or least see the code!

Link to comment
Share on other sites

Well I was hoping someone may have encountered something similar sounding and have a potential fix.

 

See the Pen YydvLq by anon (@anon) on CodePen

is a codepen, but you'll likely see it runs fine in your browser of choice.

 

There is no way I can show a live example really, as again, the issue is on a specific hardware solution.

Link to comment
Share on other sites

I think Jonathan provided everything we can (which I realize doesn't necessarily solve things for you). If I were in your shoes, I'd just try to isolate a few things (your codepen had over 900 lines of JS - I'd reduce it a lot more) and figure out how exactly that particular browser handles the stacking and then go from there. Like if applying a transform gives it a whole new context that causes it to ignore z-index, can you use that to your advantage and apply transforms to all of your elements? Once they all have transforms, does z-index have any effect? What about the "z" position (like translateZ())? Do you need to wrap each element in its own <div> whose sole purpose is to control the stacking order/context? I'd probably figure that out in a reduced test case and then create a function I can call to set the stacking order the way I know it'll work. Then just reuse that function as much as you need in order to get the results you're after. 

 

Just an idea. 

  • Like 1
Link to comment
Share on other sites

I have noticed that in some cases with webKit browsers you need to add this to the <head> of your HTML file. Don't put it in your CSS file, but only in the head of the HTML file to the classes or IDs of the images that are not respecting their z-index properties, not sure if this helps, but it has solved issues like that for me in the past. I hope that helps.

 

.yourClass{-webkit-transform: translate3d(0,0,0); }

Link to comment
Share on other sites

Mr. Pablo,

I forgot one more thing. If you have elements that are using z-index along with position absolute or fixed. And then you apply CSS transforms to them. And your z-index stacking gets out of order or lost. You could use the following on that element with the transform to resolve some z-index issues:

/* or the GSAP way transformStyle: "flat" */
transform-style: flat;

That will keep the transform 2D, but allow the z-index to work with the previous z-index applied.

Hey celi, that -webkit-transform: translate3d(0,0,0);  basically does the same as GSAP force3D: true.

It's an old CSS hack to force hardware acceleration (GPU). ;)

  • Like 3
Link to comment
Share on other sites

Jonathan, if I use the transform style you mentioned, and the transforms are kept 2D, does that mean hardware acceleration is not used any more?

Link to comment
Share on other sites

Hardware acceleration is used on 3d transforms. If your animation just uses CSS 2D transforms, it can still perform good. But GSAP has force3D set to auto by default, so its smart enough to when to use it. The best thing to do is just set up your scene so you don't have a lot of nested element with z-index. Meaning don't place z-index on child with z-index already on its parent or another grandchildren with z-index. That is when it can get hairy.

 

force3D is part of the CSSPlugin:

 

http://greensock.com/docs/#/HTML5/GSAP/Plugins/CSSPlugin/

 

Taken from the CSSPlugin Docs:

  • force3D
    As of 1.15.0, force3D defaults to "auto" mode which means transforms are automatically optimized for speed by using matrix3d() instead of matrix(), or translate3d() instead of translate(). This typically results in the browser putting that element onto its own compositor layer, making animation updates more efficient. In "auto" mode, GSAP will automatically switch back to 2D when the tween is done (if 3D isn't necessary) to free up more GPU memory. If you'd prefer to keep it in 3D mode, you can set force3D:true. Or, to stay in 2D mode whenever possible, set force3D:false. See http://css-tricks.com/myth-busting-css-animations-vs-javascript/ for more details about performance.

Also check out the stuff in there on 2D transforms and 3D transforms!

 

That is why i always put emphasis on first setting up your scene with the right CSS and some of the rules i suggested above. And what Jack suggested above. Once your scene is setup properly, then animating is easy, since you covered your bases taking the time to setup your scene the right positioning and CSS properties of your elements.. Sometimes you have to go back and rearrange or create different markup to accommodate a cross browser scene so the transforms can work correctly with z-index.

 

Best to take more time in the beginning of the setup of your HTML markup and CSS. And then you will spend less time setting up your tweens and timelines with GSAP. Since you did all the heavy lifting in the beginning of setting up your scene.

 

:)

  • 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.
×