Jump to content
GreenSock

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

Wix Wow!Team

BusinessGreen
  • Posts

    10
  • Joined

  • Last visited

About Wix Wow!Team

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,269 profile views

Wix Wow!Team's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. 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?
  2. Thanks Jack. For your question - yes, once I add TweenLite to the paths of my require config looks like everything works fine.
  3. 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.
  4. Posted a bug report on Github, linking it here too. https://github.com/greensock/GreenSock-JS/issues/154
  5. 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.
  6. 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
  7. 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
  8. My example was wrong. I meant inline style of course. someElement.style.transform = 'rotate(30deg)' someElement.style.webkitTransform = 'rotate(30deg)'
  9. 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.
×