Transform creates new coordinate system in webkit browsers

[thomask]

Hi there,

 

New to GSAP, but I'm loving the features so far. However, my current project has me in a bit of a bind. My client wants a rather unusual content slider, where each full screen slide in the slider can be scrolled to reveal further content. I thought to use GSAP to implement the transitions between the content slides, but that's where I'm stuck. I'm using ScrollMagic and GSAP to implement a pin effect within the slide, but when I transform the slide-container div, the pin disappears. I've identified this as a long-standing webkit issue where a transform creates a new coordinate system for it's child elements, so the pin is being fixed to that new system rather than the window. There are other weird issues related to the transform as well; I have a skewed element that seems to get moved downward relative to it's non-transformed self. 

 

I understand the issue, but I'm at a loss for a solution. I've tried CSS transitions, and changing positioning via classes, but they don't seem to actually generate a transition, plus access to Timeline would really simplify things for me. In the codepen example, there's a button to tween the x, which generates the transform issues, and a button to tween the left position, which generates other weird issues. I know I've got a super-niche case, but maybe others will or have run into something similar. Does anyone have any thoughts on how to approach this? 

See the Pen WQqMWv by tkaragianes (@tkaragianes) on CodePen

[OSUblake]

How is this a webkit issue? It looks the same in every browser I tried. I my not sure what you are trying to do, but if you want to use shapes, you would probably be better off using SVG and clip paths instead instead of some CSS magic.

[Jonathan]

Yes i see the same thing happening in both webkit and gecko (firefox) based browsers. I dont see anything different between latest Chrome and latest Firefox, they both look and behave the same.

 

I do notice on your top most wrapper with the class .slide you have a CSS transition: property using all value. You should remove that, since you don't want to use both CSS transitions / CSS animation with GSAP. Other wise you will have a gang war fighting over the animation.

 

Also i noticed you using z-index -1 .. that will give you issues cross browser, especially in IE and some builds of webkit. You should always start at 1 for z-index, and and arrange your elements and pseudo elements above that. And try to stay away from nesting elements with z-index. Because once you add CSS transforms it can make it harder to keep the stacking order right.

 

I'm seeing some other positioning issues having to do with pseudo-elements with position fixed, which i would have used position absolute. Since position fixed nest like that can get hairy really quick with new stacking contexts.

 

What you are describing when you say "where a transform creates a new coordinate system for it's child elements" is CSS Stacking Context. That happens with CSS transforms and in every modern browser depending when certain CSS properties are used, which will a new stacking context. Which is different than z-index.

 

Have a look at this reference article on Stacking Context

 

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

 

A stacking context is formed, anywhere in the document, by any element which is either

• the root element (HTML),
• positioned (absolutely or relatively) with a z-index value other than "auto",
• a flex item with a z-index value other than "auto",that is the parent element display: flex|inline-flex,
• elements with an opacity value less than 1. (See the specification for opacity),
• elements with a transform value other than "none",
• elements with a mix-blend-mode value other than "normal",
• elements with a filter value other than "none",
• elements with isolation set to "isolate",
• position: fixed
• specifying any attribute above in will-change even if you don't specify values for these attributes directly (See this post)
• elements with -webkit-overflow-scrolling set to "touch"

Within a stacking context, child elements are stacked according to the same rules previously explained. Importantly, the z-index values of its child stacking contexts only have meaning in this parent. Stacking contexts are treated atomically as a single unit in the parent stacking context.

 

[thomask]

Re: OSUblake, 

 

My problem isn't really with the skewing, but thanks for the tip with the clip path; I didn't realize support was so improved for this property. Also, I only referred to it as a webkit issue because of this stackoverflow thread.

 

Re: Jonathon, 

 

I thought the transition: all was commented out. It was a remainder from an earlier attempt to use CSS transitions to implement the sliding motion, but it appeared very jerky when it worked at all. Good point re: the pseudo element backgrounds being fixed. I thought I had changed those to absolute. 

 

I read another of your posts on the forum that discussed stacking context, and it was really helpful, but I clearly didn't understand till now. Thanks for clearing up stacking context for me (I've been through a lot of articles trying to fix this, but they're usually very murky explanations). So, if I understand correctly, this is completely expected browser behavior. When there's no transform, the position:fixed will be interpreted in the stacking context of the root. But when I apply a transform to the .slide wrapper, the position:fixed gets interpreted in the new stacking context. 

 

So, to fix the skewed element I've got two thoughts; set the top property of the element I want fixed to the window scrollTop and update on scroll, or translate each section independently, rather than translating the wrapper. Any thoughts on which might be better? Performance or GSAP-wise?

[OSUblake]

Support for clip-paths isn't great. I was suggesting using actual SVG elements with a clip-path.