Jump to content
GreenSock

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

Wix Wow!Team

BusinessGreen
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

4 Newbie

About Wix Wow!Team

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,548 profile views
  1. BTW - I think some warning or error message on bad value types could also be useful
  2. 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.
  3. 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 (G
  4. 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.
  5. 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?
  6. Thanks Jack. For your question - yes, once I add TweenLite to the paths of my require config looks like everything works fine.
  7. 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/TweenMa
  8. Posted a bug report on Github, linking it here too. https://github.com/greensock/GreenSock-JS/issues/154
  9. 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.
  10. 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
  11. 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
  12. My example was wrong. I meant inline style of course. someElement.style.transform = 'rotate(30deg)' someElement.style.webkitTransform = 'rotate(30deg)'
  13. 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.
×