Wix Wow!Team

BTW - I think some warning or error message on bad value types could also be useful

Thanks a lot Jack for the quick reply If you are saying that the previous behaviour is limited to a limited group of cases, that it is less of an issue to fix some places in the code (we don't use skew that much ) Thanks again Tom.

Hi @GreenSock I upgraded GSAP version in our project and some animations stopped working. I managed to reduce it to afromTo that had an undefined value in the from params. It used to work in 2.x and in 3.1.x but since 3.2.0 (and in the current 3.4.2) the animation fails. One can say - "just don't have undefined fields in your code" but as coding goes, it's not that simple and will require some serious refactoring on our part which I would prefer to avoid. Working demo (GSAP 3.1.1) - https://codepen.io/tombigel/pen/OJMdwRV Failing demo (GSAP 3.2.0) - https://codepen.io/tombigel/pen/VwegBKR

I found a bug with clearProps and opened a ticket on github a couple of days ago - https://github.com/greensock/GSAP/issues/393 I just don't know if anyone is looking at the issues there, so posting here too.

Apologies for bumping the issue, Just need to know - Jack, are you planning on addressing this? or do you consider it an acceptable behavior? Should I wait for another version?

Thanks Jack. For your question - yes, once I add TweenLite to the paths of my require config looks like everything works fine.

TL;DR I upgraded our project to use 1.19.0 after using 1.18.2 and requirejs couldn't find TweenLite unless I defined it explicitly in the require config paths object. Is it the expected behavior? We do amd with requirejs. My GSAP section in the paths object looks like this (there is also a base url defined of our external libs server): paths: { // ... TweenMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')}, TimelineMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')}, ScrollToPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/ScrollToPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/ScrollToPlugin')}, DrawSVGPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/DrawSVGPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/DrawSVGPlugin')}, // ... } This setup worked for a long time now without changing anything but version numbers up until 1.18.2. After changing the paths to 1.19.0 I got a console error by reuirejs saying it got 404 on TweenLite because it tried to load it from localhost - require.min.js:34 GET http://localhost/TweenLite.js The way to overcome it was to add a line in paths for TweenLite too TweenLite: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')}, Is it an expected behavior? Is it a bug? Am I missing something in the require config? Thanks. Tom.

Posted a bug report on Github, linking it here too. https://github.com/greensock/GreenSock-JS/issues/154

Hi, following up on a year old topic http://greensock.com/forums/topic/9790-will-change-property/ The will-change property is getting some traction lately, it is supported by 3 out of the 5 major browsers and is considered by MS Edge. I was wandering if any work or research was done about adding support (manual or automatic) to GSAP for this? A nice video demo by a google dev demonstrating the performance implications will-change can have: Thanks Tom B.

yes , in the latest preview it seems to be solved.

another case that make a wired mirror flip (happens on production version) IE 11 , an element with transform rotate of 91 degrees and applying animation to 90 degrees rotation. http://codepen.io/yanivz/pen/qEObbR

I have tested 1.14.5_preview5 version for the above scenario. the issue exists.. On Webkit/Gecko when translateZ value = 0 (reproducible on previous version when Z > 0) On IE 11 it seems ok. http://codepen.io/yanivz/pen/XJbyxr Yaniv

My example was wrong. I meant inline style of course. someElement.style.transform = 'rotate(30deg)' someElement.style.webkitTransform = 'rotate(30deg)'

I came across an unexpected behaviour: apparently Chrome 36 and up supports both prefixed and unprefixed 'transform' property. So, if you set initial transform values on an element (not with GSAP) like so: someElement { -webkit-transform:rotate(30deg); transform:rotate(30deg) } and do TweenMax.set(someElement, {clearProps: 'transforms'}) only the unprefixed version is being cleared and the rotation remains on the element.