Tom B. @ Wix

Hi Jack! Long time Thank you for the elaborate answer! you and @Cassie gave me plenty of ideas to try About my last question, forget it, I’m over engineering things in my head ?. I’ll just test it for myself. thanks!

Interesting! But then gsap won’t be “aware” of what it’s animating, right? It will just enumerate a number and automatically do setProperty every animation frame?

It’s not a bug, it a feature, and a very strong one. you can do amazing things like that, and when we’ll have @property everywhere we could do things in css that are not possible in js

In my original post codepen, I want the purple (gsap) box to animate like the blue (css) box.

Hi Cassie! thanks for the quick reply! Sorry, I originally thought I found a bug in the gsap transformOrigin implementation and made an elaborate codepen last night. Today I realized the bug was in my code… anyway, i want to be able to get the gsap animation to do what “first rotateY then rotateZ” does in css. Animating the entire transform string is an interesting option I haven’t thought about, but it defeats the purpose a bit (I guess it will override the entire transform string like css animation so, right?) Any other trick you know of I can do to achieve the same result? thank you!

I am trying to rotate a Z rotated element on the X/Y axis + perspective and transform-origin, and just can't get the GSAP result to be the same as with the CSS animation result. (My question relate to the attached codepen) In CSS I can first rotate the X component and only then apply the Z rotation, which creates a different animation than the other way around. GSAP (as far as I know) has a fixed transforms order (I remember @GreenSock writing about it years ago), but still, I tried and tried and wasn't able to get the same animation in both CSS and GSAP (using a single element) Thanks!

Thanks for the detailed answer Jack. 1st - GSAP is not letting me down in any way. I worked around this days ago on my side. As you said, part of the problem was bad practice on our side But as you can imagine in a project like the Wix Editor we are stretching the abilities of the browser and of various frameworks we work with to their max. You won't believe how many weird edge cases and bugs we encountered and worked around or solved in the past couple of years. We work with libraries like GSAP, React, RequireJS, Zepto, Grunt and many others on the client side, and even more on the server side, and we contribute back tons of enhancements and bug fixes every day. To the topic - This bug is a new bug. It doesn't exist for so long, just since chrome 36. Also, many frameworks and preprocessing tools don't try to detect browser prefixes, they just add all the prefixes for the browsers you tell them you support (the very popular Autoprefixer for example). As a framework maintainer you know that you are not living on your own isolated island, you have hundreds of other frameworks and the browsers themselves you have to play nice with. Also, stupid browser bugs come and go with every version and we as developers that our work is seen by millions of people every day have to deal with them. even if they are arbitrary or temporary or not our fault. Thats it. I'll stop poking this issue now.

Hi Jack, as I told you some time ago, we rewrote our entire system with ReactJS. React uses it's own (very cool) method to render HTML - The general idea is that It holds a virtual JSON representation of the DOM and handles DOM reads and writes for you using precise JSON diff methods in a very performant way. So When you build a site based on React components you actually never interact with the DOM, you interact with React, and React in it's turn decides when its the best time to read or write the DOM. Some of the consequences of this method is that you get a lot of inline style declarations for mutable values, and, you don't have the opportunity to use DOM heavy tools like GSAP to do elementary operations. We use GSAP almost solely for animations, which by their nature happen after the rendering lifecycle of a site ended, after everything is built and presented to the user where it cannot interfere with with DOM read/write performance. This specific bug happens where someone applies a rotation (not a rotation animation) on a component and the system just applies it somewhere in the rendering process. I eventually worked around this by writing a more robust browser prefix detection function for css transforms, so the -webkit- prefix is no longer applied in Chrome. I still think that since this behaviour of chrome is non-standard, frameworks that by design are built to spare the user the hassle of handling browser prefixes should handle it too. Thanks for the quick replies btw. GSAP Rocks!

I've come across a bug when applying a transformation on an already rotated element with 3d rendering enabled: You can see the codepen for the live preview I have an element with 180deg rotation and Z transform: <div id="aa" style="transform:rotate(180deg) translateZ(10px)">I'm rotated 180 Deg</div> // On Webkit/Gecko this happens only with z > 0, On IE it happens also with z == 0 And then I run some transform animation on it TweenMax.from('#aa', 2, {x:'+=100'}) The result is that the rotated div flips back to 0 degrees, or, from matrix(-1,0,0,-1,0,0) it transforms to matrix(1,0,0,1,0,0) This does not happen on other rotation angles.

Sorry for being rude, but you are both stating the obvious, and missing the point. When using Greensock I'm not supposed to worry about vendor prefixes. This is a bug, since I clear the transforms but because of a non-standard Chrome behaviour they are not completely cleared. (Sorry for using 2 different users, the other one is my team's club member user )

oh... this is a bit stupid.

I stumbled upon a weird behaviour of clearProps, and couldn't find any reference to whether it is a bug or not. When using clearProps with explicit values the order of the parameters passed has importance when clearing mixed transforms/properties values. This will clear x and y and skip opacity - clearProps:'x, y, opacity' This will clear only "opacity" and skip x and y. clearProps: 'opacity, x, y' Same goes with other non transform values like "clip" See the codepen for clearer example.

Hi I'm building an infinite horizontal image slider that slides when the user hovers over a 'next' or 'previous' buttons. The design requires the animation to gradually pause/resume with a subtle easing and not pause immediately. the only solution I found was to use an infinitely repeating tween for the slider, and attach a second tween to the buttons that tweens the 'timeScale' of the original tween with an easing. Is there a simpler native way to do so without creating a second tween? Thanks

Looks like it works. Cool. thanks