Search the Community
Showing results for 'resize' in content posted in GSAP.
Found 2,314 results
-
Thanks for all the help on this. I did implement Rodrigo's suggestion. Be sure to resize the browser to the div size(will fix that later - limitation of the viewport plugin used). On codepen: http://codepen.io/cmmize1/pen/gltzw Sample site: http://www.pradev.com/one-page/sample.html On an ipad (both chrome and safari) the screen flickers at the end of the drag, I'm thinking it is when I destroy the draggable instances and recreate the new one. Any ideas on how to stop that? In your opinion, is this the best way to go about this for a one page multi-directional web site?
-
Hi Abhilash, In that scenario the best recommendation is work with percentages and as Jack pointed either create all the tweens again (if necessary), you can achieve this by creating the tweens/timelines in a function, and call the function that creates the tweens/timlines on resize. You might find this post useful: http://forums.greensock.com/topic/9063-best-approach-for-conditionally-disabling-tweens/ Also is always better to see a reduced live sample, please also check this post: http://forums.greensock.com/topic/9002-read-this-first-how-to-create-a-codepen-demo/ Rodrigo.
-
If your not using jQuery in your site than window.resize should work just fine. Glad you got it figured out!
-
Hi Jonathan, thanks for your help. I shortened the code in order to work in CodePen. http://codepen.io/anon/pen/ABvqm What i'm trying to fix is the rollOver state, you will notice that the green panel should always cover the text with a 25px padding. this comes from this variable bgHeight = $(element).find(".text-box").height()+25; The issue is that when you resize the window, you will notice that the green panel will not cover the text properly, but if you refresh the preview area, it will be fine. Let me know if that makes sense. Cheers, Thales
-
Hi, yeah i think what i need is the resize event, the only thing i'm not sure about is the code that would refresh the variables. for example: bgHeight = $(element).find(".text-box").height()+25; The height of the element changes as the window resizes but the variable remains the same. Cheers, Thales
-
When doing a className based tween, the unit of properties is not respected. Here is an example: http://jsfiddle.net/KxfUN/ I would expect the tween to see that the start value is a percentage for the top property, and the end value is a percentage, and adhere to that unit. However if you inspect the element during the tween, it uses pixels. If I'm able to explicitly use percentages in other CSS tweens (ie TweenMax.to(element, duration, { css: { top: "50%" } }) ) then it should behave the same in className based tweens, no? I think this is valuable in the rise of responsive websites where viewports are of varying sizes, and percentages allow developers to create "fluid animations" (using percents or other dynamic units) that work everywhere. If I resize a browser amidst a paused tween thats done these conversions, it's likely going to produce undesirable results.
-
ScrollTo bug in 1.8.2 in Safari 6.0.2 & Mountain Lion
jamiejefferson replied to sibhod's topic in GSAP
Ah, here's the scroll throttling code Carl mentioned. You could also utilise the excellent throttle-debounce plugin by Ben Alman for this. Debounce: Wait until scrolling is complete to run code: var scrollTimeout; $(window).on('scroll', onscroll); function onscroll(e) { clearTimeout(scrollTimeout); scrollTimeout = setTimeout(scrollcomplete, 200); } function scrollcomplete() { // code to run after scrolling here } Throttle: Run code throughout scrolling, but at a lower rate than the scroll events: var scrollTimeout, scrollactive = false; $(window).on('scroll', onscroll); function onscroll(e) { if (!scrollactive) { scrollupdate(); // throttle the next scrollupdate scrollactive = true; clearTimeout(scrollTimeout); scrollTimeout = setTimeout(function() { scrollactive = false; }, 200); } } function scrollupdate() { // code to run during scrolling here } Actually, it looks like you are doing something similar for your resize events already... -
I see what you mean, and we'll look into this for a potential future release. We're working very hard on a few other features right now, and given the fact that the px tweens visually look the same (unless you resize the browser mid-tween, as you mentioned), it's somewhat of an edge case that we can't prioritize quite yet. It's not as easy to implement as one might think Thanks for bringing this up, though.
-
Hi guys, So I have a "default" class for an element that places it offscreen and ready to be animated in. I remove the "default" class in the tween which works just fine. <style> .myelement { left: 0px; } .myelement.default { left: -200px } </style> TweenLite.to(".myelement",speed, { className: "-=default" }); Now, I have some scaling logic in place that is fired on resize. When resized, the "left" property is updated which now needs to overwrite the ".myelement" left value contained in the element's .myelement class. TweenLite.to(".myelement",speed, { className: "-=default", left: "-300px" }); My guess is that the ".myelement" left value is overwriting the passed "left" parameter. Any suggestions on optimizing this is greatly appreciated. - Mike D
-
Thanks you Carl for providing the GSAP way! This actually brought a few things into perspective for me. A couple things though. First, I'm not sure the easing is being used. I forked your fiddle and added the EasePack plugin (since I realized it was missing to begin with) but that didn't seem to help. New fiddle here. Second, I'm also currently looking at a way to draw a path without using the clear() method on the paper with the goal being that I'd be able to draw one shape via a path, then convert that into a standard shape after the animation completes (which I'm not sure how I'd address just yet, but figure that's a common task in Raphael), then "chain" the next path animation, continuing until all animations have been drawn to the screen and converted to shapes that could then be scaled on window resize. Here's a fiddle of where I am with that if you feel like another challenge. My main question though is in regard to the easing, as I understand the other aspects may be out of the scope of what you guys want to support via the forum. Thanks again to you and all the guys here at Greensock!
-
Its ok.. I faked a click by calling startDrag after a screen resize this seems to sort everything out. So all good.
-
Once you have declared a draggable object is there away to delete it again? The reason I ask is that I have page that works really well controlling multiple tweens as you drag the container. The problem comes if the browser is resized and I get all sorts of odd results. if you hit refresh then it works fine. So my thinking is the easiest way to get around this would be to redelclare everything after a resize. I've done this for the timeline animations but i can't seem to find a way to get rid of the "draggable" once it has been set. There is a "disable" but what I would like to do is completely remove it.
-
Yep, disable() is all you need. Is that not working for you or something? Also, could you provide a very simple codpen or jsfiddle that demonstrates the odd behavior after a window resize?
-
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});
-
Concatenating a relative percentage value for tweening
Gary Horsman replied to Gary Horsman's topic in GSAP
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);
-
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?
-
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.
-
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, 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!
-
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.
-
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.
-
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.
