Search the Community

i want to ask an additonal question to this topic please! i write a small interface script: http://tvim.de/scrollto/scrollto.html it works brillant! Thanks to Greensock Team! But when i resize the window, it has problems centering my divs. without greensock there are no position problems. i think its because greensock uses "px" values to calculate scrollTo destinations. but can i have them with percentage? i tried it but it does not work: TweenLite.to(scrollsrc, 1.5, {scrollTo:{y:"30%", x:"30%"}, ease:Power4.easeInOut});

The viewport container for the slides is actually 100% the width of the browser window, so there is no specified pixel width. If it were in pixels, my problem would be solved! Each slide is 1/6 (or about 16.66667%) of the slide container, and that slide container is 600% of its parent container which acts like a viewport with a scrolling overflow and THAT viewport is the one that's 100% of the browser window. So everything has to resize inside a liquid layout. That's what the client has requested. Yes, the slides are moving only on the x-axis. Unfortunately, I've never set up a codepen or jsfiddle page, though the link in my last post is a codepen page. But I'm thinking the solution offered there is a much more elegant solution to making the proper conversion between percentages and pixels than my little disaster If it works, I'll post the solution adapted to my situation.

You're right, the resizing you describe is not a built-in functionality provided by GSAP Draggable. If you take a look at this codepen, you can see a method that gets GSAP Draggable and jQueryUI Resizable working together. The trick is in this line, that prevents the resize and drag from happening at the same time: $('.ui-resizable-handle').attr('data-clickable', true);

I am attempting to resize a draggable DOM. As in the user can select an edge of the DOM and drag it to a new size. Is this something that GSAP is designed to handle or am I on the wrong track? jQueryUI 'resizable' doesn't really work with a draggable (or I haven't yet been able to get it to work).

Jack, Thank you for the quick reply! Yes, so basically, what I had thought to test was if the a website/page was built using a responsive grid (i.e. Foundation, or Bootstrap), and when the user resizes their window the ".arrow-test-wrapper" (percentage base, say .row.column) would resize. So, I wondered if the bezier curve positions would alter themselves relative to that parent element. I assumed that the values would not take in a percentage, integers only?

Thanks for the help, but it's still not working exactly right. Following your example, I'm setting the "y" value right when the tween starts, and then resizing the browser and inspecting the results. So theoretically, if I resize without scrolling, tl.progress(0) ought to reset the y value immediately. castTween.updateTo( posObj({ y: $(window).height()})) ; The posObj function just does a few hacks for IE8 that aren't relevant here since they're not triggered. I then look in the debugger and I can see that the original height was around 440, and the new window height is indeed much higher (in this case around 650). I look in Firebug, and the results are still like this: <section id="cast-landing" style="display: block; top: 0.05px; transform: translate3d(0px, 444px, 0px);"> </section> So it's not updating that translate3d property at all. What am I missing?

Hi, I'm having trouble getting this to work, so I'm wondering if anyone can help? Basically, I'm creating a TimelineMax instance and populating it with some tweens. One of the tweens I'm using to set a div at exactly the window height and another at exactly 0 (cleaned up to make it more generic): tl.to(selectors.$myElement, 0, posObj({ display: 'block', y: $(window).height(), z: 0.001}), "myLabel"); The problem is that the div heights are being resized on browser resize, so that two divs stacked up on each other no longer butt up against each other. I tried approaching it by looping through the tl.getChildren, finding tweens with a "y" var, then updating that number with the new window height, but this doesn't seem to be working as expected. var updateTweens = function () { tl.getChildren().map(function ( item) { if(item.vars["y"]){ if(item.vars["y"]==windowHeight){ item.vars["y"]=$(window).height(); } } }); }; So is there a better way to accomplish this? Bear in mind that I have around 30 tweens to work with and when I tried to use the "tl.add(var myTween=new TweenMax(el, time, vars));" approach everything sort of broke. But any help is greatly appreciated.

Hi, It would be best if you could take some time to boil this down to just the key elements. We really only need to see code that: determines the final, centered position of the graphic in question animates the final graphic and if necessary the code that reloads the page on resize. Right now there are just too many variables and calculations to sort through and testing the animation requires us to watch things animate that aren't necessary and take time. The simpler the codepen is the quicker we can get to the bottom of the issue. Thanks!

you could try using one of the GSAP kill methods to stop / clear / kill the animation so when the resize event fires and checks with your if statement that the animation is killed and runs the tween again: here are the available kill methods: _________________________________________________________________ kill() Kills the animation entirely or in part depending on the parameters. http://api.greensock.com/js/com/greensock/core/Animation.html#kill() //kill the entire animation: myAnimation.kill(); //kill only the "x" and "y" properties of the animation (all targets): myAnimation.kill({x:true, y:true}); //kill all parts of the animation related to the target "myObject" (if the tween has multiple targets, the others will not be affected): myAnimation.kill(null, myObject); //kill only the "x" and "y" properties of animations of the target "myObject": myAnimation.kill({x:true, y:true}, myObject); //kill only the "opacity" properties of animations of the targets "myObject1" and "myObject2": myAnimation.kill({opacity:true}, [myObject1, myObject2]); _________________________________________________________________ killAll() Kills all tweens and/or delayedCalls/callbacks, and/or timelines, optionally forcing them to completion first. http://api.greensock.com/js/com/greensock/TweenMax.html#killAll() //kill everything TweenMax.killAll(); //kill only tweens, but not delayedCalls or timelines TweenMax.killAll(false, true, false, false); //kill only delayedCalls TweenMax.killAll(false, false, true, false); _________________________________________________________________ killChildTweensOf() Kills all tweens of the children of a particular DOM element, optionally forcing them to completion first. http://api.greensock.com/js/com/greensock/TweenMax.html#killChildTweensOf() <div id="d1"> <div id="d2"> <img src="photo.jpg" id="image" /> </div> </div> <div id="d3"></div> TweenMax.to( document.getElementById("d2"), 1, {css:{left:100}}); TweenMax.to( document.getElementById("image"), 1, {css:{left:100}}); TweenMax.to( document.getElementById("d3"), 1, {css:{left:100}}); //only kills the first 2 tweens because those targets are child elements of the "d1" DOM element. TweenMax.killChildTweensOf( document.getElementById("d1") ); _________________________________________________________________ killTweensOf() Kills all the tweens (or specific tweening properties) of a particular object or the delayedCalls to a particular function. http://api.greensock.com/js/com/greensock/TweenMax.html#killTweensOf() TweenMax.killTweensOf(myObject); TweenMax.killTweensOf(myObject, {opacity:true, x:true}); _________________________________________________________________ You could use any of the above GSAP methods to stop the animation which.. or kills the animation entirely or in part depending on the parameters and what method you use In your case you can try using the killTweensOf() method: $(window).resize(function(){ var ww = $(window).width(); if(ww < 1350) { var ha = document.getElementById(home-art); TweenMax.killTweensOf(document.getElementById(home-art)); TweenMax.set(ha,{'left','-350px'}); } if(ww < 1780 && ww >= 1350) { var ha = document.getElementById(home-art); TweenMax.killTweensOf(document.getElementById(home-art)); TweenMax.set(ha,{'left','-200px'}); } }) if you notice i have the ha variable in each if statement so it only tries to find that element if the width meets the conditional. This way the resize event doesnt have to keep checking the DOM when the width if conditional isn't true. also using document.getElementById() is faster than using the jQuery element object selector. http://jsperf.com/getelementbyid-vs-jquery-id/13 also you will notice i used the GSAP set() method to set the css properties instead of using the jQuery css() method http://api.greensock.com/js/com/greensock/TweenLite.html#set() try that and see if that helps..

I'm not sure this will achieve anything. Let me give you some code as an example. $(function(){ app.init(); }); var app = new App(); function App() { var animations = { homeSection = new TimelineMax({paused: true}); } function _initAnimations() { animations.homeSection.from("#home .background", 1, {css:{opacity:0}}) .from("#home-art", 0.75, {css:{opacity:0, left: -100}}, "homeart") } this.init = function() { _initAnimations(); } } This is the basic setup of my App. My problem is, when _initAnimations() fires on page start, the CSS (dependent on media queries is called) is pulled in by GSAP. For example: #home-art { background: url(../images/ui/sections/home/art.png); width: 1327px; height: 769px; position: absolute; left: 0; } @media (max-width: 1780px) { #home-art { left: -200px; } } @media (max-width: 1350px) { #home-art { left: -350px; } } So for example, the page is loaded with a window between 1350px and 1780px. #home-art will become left: -200px. If I resize the page to between 1000px and 1350px and I use a $(window).on('resize') event, like this: $(window).resize(function(){ var ww = $(window).width(), ha = $('#home-art'); if(ww < 1350) ha.css('left', '-350px'); if(ww < 1780 && ww >= 1350) ha.css('left', '-200px'); }) The left is set to -350px via javascript and all is well. The PROBLEM, however, occurs if I change sections, and then go back to the home section (meaning I am replaying the animation). GSAP still thinks that the #home-art offset is still -200px and animates to that, when it should be -350px, now (based on media-query or javascript). I guess real question is. If my animations are defined on load, how do I repopulate the {css:{left: x}} offset in real time? Defer the home animation initialization and have it define on resize? Or is there a way for me to modify this value in GSAP on the fly?

Hello and Welcome to the GreenSock Forums Without seeing any or all of your code... You could try setting a resize event handler: $(window).on('resize', function(){ animations.homeSection.from("#home-art", 0.75, {css:{opacity:0, left: -100}}, "homeart"); }); also depending on your media query you can also check your content widths and adjust accordingly: $(window).on('resize',function(){ if($('#content').width() >= 400){ // tweens or code can go here } else if($('#content').width() >= 800){ // tweens or code can go here } }); you get the idea.. you basically check the width of the container you are testing against for the width in the media query and then apply your tweens when it meets your specif widths or test between a specific width range: if($('#content').width() >= 400 && $('#content').width() <= 800 ){ // tweens or code can go here } this would check to see if the content width was above 400px but below 800px does that what you mean?

Hi there, I'm new to GSAP. I'm doing my first build with it and am loving it. I am running in to a bit of a problem in regards to element placement and where they are defined with media queries. My app defines its animations and initializes them all on page load. This is working wonderfully for all my animations with the exception of the home page. The problem with this animation is I am currently using media queries to position an element based on browser viewport size, so certain elements don't overlap, etc. This works fine when the page is loaded for the first time. GSAP grabs the correct CSS offset and animates the element in via: animations.homeSection.from("#home-art", 0.75, {css:{opacity:0, left: -100}}, "homeart") The problem is, when this animation is initialized on page load, it grabs that CSS and sets it on the element in-line. Now if I resize the browser window, the element does not respond to the media queries and things overlap. I was trying to do some window.onresize things but have been largely unsuccessful at this point. If I manually set the css:left property of the element based on window sizing inside of a window onresize, when the page is reanimated, it reverts to the originally calculated position by GSAP. Is there any way around this? Thanks ahead of time.

I noticed that in your init() function your first line has this: // your using opacity TweenMax.staggerTo('.thumbnail', 3, {opacity:'1', delay:0.5, overwrite:"all"},0.07); And then when images are loaded you are using this: // Once images are loaded, init Packery and fade on images imagesLoaded(container, function() { pckry.layout(); // and here your using alpha TweenMax.staggerTo('.thumbnail', 2, {alpha:'1', delay:0.5, overwrite:"all"},0.1); }); Is there any reason why you are running this code before the images are loaded and then again inside the imagesLoaded callback? Also your using two different types of properties to animate.. first you try staggerTo opacity to 1 .. and then after images are loaded you try to set alpha to 1 Have you tried just commenting out the first staggerTo, and only use the staggerTo in the imagesLoaded callback also what about using autoAlpha:1 instead of opacity or alpha: var MasonryLayout = { // ------------------------------------------------- // SETUP // ------------------------------------------------- init: function() { // leave this line commented out // TweenMax.staggerTo('.thumbnail', 3, {opacity:'1', delay:0.5, overwrite:"all"},0.07); // Bind container and establish settings var container = document.querySelector('.masonry-holder'); var pckry = new Packery( container, { itemSelector: '.thumbnail', gutter:0, rowHeight: '.grid-unit-25' }); // Once images are loaded, init Packery and fade on images imagesLoaded(container, function() { pckry.layout(); // instead of alpha you could use autoAlpha: 1 or use opacity: 1 TweenMax.staggerTo('.thumbnail', 2, {alpha:'1', delay:0.5, overwrite:"all"},0.1); }); // force window resize to make sure content is centered $(window).trigger('resize'); } }; autoAlpha:1 basically sets the opacity to 1 and then sets the visibility to visible or inherit autoAlpha:0 basically sets the opacity to 0 and then sets the visibility to hidden you can learn about autoAlpha here, scroll down and find autoAlpha: http://api.greensock.com/js/com/greensock/plugins/CSSPlugin.html let us know if that helps

Hi Jack, I checked it out and it does the job, awesome work! 2 remarks: - I update the dragResistance of each node at runtime by directly setting the .dragResistance property, is this the recommended way or is this 'hacky' (i.e. should there be a setter function)? - I actually needed a negative dragResistance because I decided to scale the contents down rather than up. I found out that setting it to -1 works to speed up the dragging by a factor 2. So it's fine by me, I'm happy it's supported in the first place, though it feels a bit unintuitive to put a negative number. A bit unrelated: What is the recommended way to scale the contents of a "scroll" without increasing the scroller itself? there are some unexpected things happening when I scale the contents of a "scroll" draggable using css transforms (i.e. the scale property). Because I don't want the draggable container itself to scale, I put everything in a wrapper div which I scale with TweenLite. However, zooming in and out (by multiple doubleclicks), the width of 'your' injected wrapper does not revert back, not even after disable and re-enable, hence the scrollable area is way too big. Also, this behavior is browser specific (on iPad it does resize itself back, on Chrome it doesn't). You can see this behavior if you doubleclick twice in the following example, and then pan to the right (there is a black area). Additionally, the edgeResistance at the bottom and right edge seem to reset to 1 in the process. http://codepen.io/ratchet/pen/Ihmgz (dragResistance obviously does not work in this example since the library is loaded from the cdn)

Hi and welcome to the GreenSock forums. Here is a basic example of infinitely repeating clouds: http://codepen.io/GreenSock/pen/drCFD Each cloud is dynamically generated, positioned and placed in a TimelineMax that repeats. For extra flavor I place each cloud's timeline inside another timeline so that all the clouds can be paused, reversed or played very easily. Since I am animating the clouds left property to 100% you will also note that you can resize the browser window and the animation continues to work fine. I commented each line of code. Let us know if you need more help or explanation.

Hi Harry and welcome to the forums, One chance could be to create the draggable instance through a function that you could execute on DOM ready or window.onload With that function you can get the draggable element's parent new width and apply to the bound variable: var parent = $("div#scrubberParent"), scrubber = $("div#scrubber"); fucnction createDraggable() { Draggable.create(scrubber, { type:'x', bounds:parent }) } So with a resize event you can call that function again and reset the draggable element's bounds. Jack in this case, creating the draggable instance more than once, is there garbage collection or overwriting for the previous instance? Hope this helps, Rodrigo.

Hey Guys, I'm using the Draggable component in a horizontal list view that is responsive. Here's an early prototype http://lab.harrynorthover.com/timeline/. As you can see in the prototype, the content above the draggable component is responsive and will resize down to 640 pixels. The issue I am having is how to scale down the scrubber at the same time. Is there a way to adjust the translate3d values through Draggable so the scrubber scales down at the same pace? I've tried scaling down the width of the scrubber or applying a negative margin left but then the drag amount becomes offset/incorrect. Is there a way to refresh the Draggable component, or scale the values down to it keeps in proportion with the rest of the content? What's the best practice for tackling resizing issues like this with Draggable? Also, is there a way to invert the direction of the dragging? So the timeline moves in the opposite direction? This is an excellent component by the way! Thanks, Harry.

Hi there, animating opacity of a png with transparent parts shows bugs in IE8, i believe because the same MSIE filters are used to animate the opacity and to display the transparency of a png - and now they overwrite each other. This is a screenshot in the middle of the animation. I can confirm that this has to do with the filters, because if i apply filter:alpha(opacity=80); to an element with a png (with transparent parts) as a background-image, the effect seen in the screenshot is permanent. While i can fix this by not applying the opacity filter on the element, i can't fix the animation part. Here's a stackoverflow-question about the same issue. If you're considering adressing this issue in GSAP animations, keep in mind the issue is not only for IMG tags but for background-images as well. I'd provide a fiddle, but neither JSfiddle nor Codepen seem to have IE8 support (who knew? :-/ ) On a sidenote: "Drag to Resize" in this forum editor doesn't seem to work (current Chrome, Windows 7).

Hi, I had a similar problem - have to tween fullscreen div . This is what I did: 1) used debounced resize to calculate the position ( I have a variable called "step" and I calculate it on every resize based on the window width: //or you can calculate just onResize() $(window).smartresize(function(){ self.onResize(); }); then: onResize: function(){ var self = this; var winWidth = $(window).width(); self.bgPercentStep = (0.5*winWidth) / self.numSlides; // } And the tween TweenLite.to( self.$bgImage, self.settings.transitionTime, { x: "-" + parseInt( self.currentSlideIndex * self.bgPercentStep ) + "px" }) If you need help with this, just post me your code I'll try to respond you on the next day. Cheers, Ico

hi, You could store that value in a general scope variable and for orientation changes you can use a resize event in order to change that value to the current one. Hope this helps, Cheers, Rodrigo.

I cracked your page open in Chrome's Dev Tools and there were HUGE paint times pretty consistently (which has nothing to do with GSAP). Literally 60ms just for an PNG image decode on almost every frame. Keep in mind that the target budget is 16.7ms for everything per frame. That's definitely the issue. Chrome is known to prioritize image quality over performance when rendering, so if you're having the browser resize an image (render it at a non-native size), it's very expensive. Are you saying this ONLY happens when you've got the same codepen page open in two tabs simultaneously? I wonder if that's just a Chrome bug related to doing an image resize in one tab on the same asset that's in another tab at a different size (totally a guess). There's a small chance it's related to codepen itself and the iframe stuff it does. Either way, I'm pretty confident the issue is unrelated to GSAP specifically. I'd definitely recommend getting familiar with Chrome's Dev Tools and its timeline view. There are some great videos out there on YouTube by Paul Irish and Paul Lewis about that stuff. Happy tweening!

Hi. I have recently begun redesigning my website at http://www.kurrent.com from Flash to HTML5. I am using the JS GSAP v1.9.7. My beta site is at http://www.kurrent.com/htmlsite. I tested on Firefox and Safari on the Mac with good results. It also runs fine in Safari on the iPad1, but it doesn't work in the Safari browser on iPad2. The page loads and the rectangles resize, but that's it. I've looked through the forums and am still scratching my head at this one. Thanks in advance for the help! Kurt

I have a grid of thumbnails (6 columns / 5 rows) that I'm animating on load and resize. On load the columns stagger from left to right into the page. On resize the rows stagger down off the page, and then the columns re-enter from left to right. The number of columns, rows, tn size and position are based on window width and aspect ratio. I'm using autoAlpha to hide/reveal column 6 and row 5. The code/conditions for the rows are working as expected. The problem I'm having is with column 6 on "resize only". 6 cols if window width >1200px 5 cols if window width <= 1200px If 6 cols enter on "load" everything works always as expected. When resizing ww <=1200px, grid exits down, then 5 cols re-enter from left (col 6 hidden). Then if you resize ww >1200px, grid exits down, then 6 cols re-enter from left. Everything works fine no matter how many times the ww is resized. If 5 cols enter on "load" there is a problem with col 6 on "resize". When resizing ww >1200px, grid exits down, then col 6 becomes immediately visible in it's end "x" position (farthest right) and the remaining 5 cols re-enter from left. Column 6 should become visible "but" positioned off the page to left, then stagger in with the other 5 cols. My thinking is the autoAlpha event is firing before being positioned, even though it is called within the positioning function. I have tried putting autoAlpha at the end of a TimelineLite timeline, used a positive position offset, etc, mostly with worse results. I have also tried staggerTo using an x start position -(ww+500). They position and size correctly but for some reason they don't enter into the page using a variable ie: "+=ww+500" but it does work with just a number within the string "+=1400". If I use the staggerTo method I can't use a fixed number if I use a variable for the starting negative offset. If I do use a fixed number that will insure that the grid clears all different window widths ie: -3000px, the entrance speed won't be consistent across different window widths. I've uploaded copies of the files (the tn images have been replaced with solid colored jpgs) http://www.peterdavidian.com/gsap/staggerFrom.html I've searched the JS forums but couldn't find a post with a solution. It's been days now (really almost a week) and I need someones help! Thank you, Peter My functions: dLoad: sizes and positions the grid container tSz: sizes the tn's tPos: sizes and positions the number of cols and rows tEnterR: staggers the cols in from left tExitD: staggers the rows down, then calls tReEnterR tReEnterR: calls tSz and tPos then staggers cols in from left

Thanks for all the explanations. I kind of feel bad that I'm taking up so much of your time that you could spend on more productive ventures. I agree with you completely in terms of performance, and I'm fully understanding you. And I agree gsap performs as desired for common use cases. I wouldn't want to change this default behavior, especially as you've explained it. I do believe a future "clear/forget element" function would be a good addition, and would also add that this is kind of what I'd expect clearProps to do. But I understand that's a cssPlugin feature, so it affects the scope of that plugin, but would expect a tweenlite counterpart. Someone recognized the need for it, so it's a matter of consistency. But personally I don't even need it, as you've given me plenty of information to create it myself, thanks. I know my needs might not seem common, but I assure you they're practical. I'm not sure if you understood what I'm doing. For a casual javascript user who wants to make a banner animation using CSS transforms, gsap makes it a breeze with entry level skills. But doing a fullscreen animation on a responsive width website becomes a maze of calculations on top of calculations to give a consistent look. This is the problem I'm solving. You just wrap your a-z animation in a function using a simple API for creating any dom element using relative sizing and placement, and the plugin automatically handles resizing it so it's identical at any size, with the added benefit of cool out of the box animations included. Recreating the timeline is simple and fast, but recreating the dom elements on each resize would be horribly slow, therefore I have to recycle and reset those elements. Hence, this is a very practical use case. Thanks for all the help, I got what I need to finish it

What kills me is that I have a much larger animation and much more robust version of the tool in that codepen. With text, images, tons of layers, complex animations, and the tools to manipulate them easily... After the resize, just about the whole animation seems to look fine, except the layer rotation no longer works, but everything else looks fine! I hope someone can spot a problem...