GreenSock

I'm so sorry about the delayed response. Slipped through the cracks. The problem in the link you provided is unrelated to ScrollToPlugin - it's actually codepen. Here's the error being thrown: "Error while parsing the 'sandbox' attribute: 'allow-modals' is an invalid sandbox flag." I guess iOS doesn't like that. Weird. If you go to the "debug" version of that link so that there's no codepen iframe, it seems to work great. If you're still having trouble, though, please provide a reduced test case that we can peek at and we'd be happy to look into it. Oh, and I know that historically iOS has had bugs that caused it to mis-report the current scroll position and that'd trigger the autoKill in the tween (because it's acting like the user tried scrolling the page manually, so the tween releases control for better UX). In other words, when ScrollToPlugin sets the scroll position, on the very next tick it says "hey, are you still where I set you? If so, I'll proceed; if not, I'll kill that part of the tween". You can disable this feature by setting autoKill:false in your scrollTo vars like: TweenLite.to(window, 1, {scrollTo:{y:"#element", autoKill:false}});

(I was typing my post when you were adding your other one...) The reason your code didn't work was that you were adding a bunch of tweens to one timeline, then (before anything played), you were reversing the SAME tweens and adding them to a different timeline (which removes them from the previous parent). Think of tweens like DOM nodes - they cannot have multiple parents. They must live somewhere (can't be two places at one time). Otherwise, imagine what would happen to their playhead if two different timelines were both fighting for control, one going forward, the other backward.

I don't think it's wise to reuse a single instance in all those cases because it sounds like you'll have too many different pieces all trying to control the same playhead (and potentially conflicting). Well, you could do it by pressing other tweens into service for controlling the playheads, but I'm not sure you'd find it as intuitive. Example: homepageTL.to(tweenCTA, tweenCTA.duration(), {time:tweenCTA.duration(), ease:Linear.easeNone}, "start+=1.125") .to(tweenIconAll, tweenIconAll.duration(), {time:tweenIconAll.duration(), ease:Linear.easeNone}, "start+=2.25") ... Notice I'm literally using other tweens to animate the playhead of your "real" tweens. But if I were you, I'd probably take a more straightforward approach instead, and just tween to the values you need when you need them. Create new tweens - we've made the system extremely efficient, so you don't need to feel like you've gotta reuse instances to be efficient. So, for example, if you've got a button rollover that plays/reverses a tween, that's fine, but then for your timeline animation just create a new tween for that. Make sense? Also, whenever I see somebody adding a bunch of tweens using labels with relative times like "start+=1.125", "start+=2.25", "start+=2.25", etc., I want to make sure they know about the power of nested timelines because those could really help make your code more modular and easier to edit. For example: function buildStart() { var tl = new TimelineLite(); tl.add(playSplit) .add(tweenCTA, 1.125) .add(tweenIconAll, 2.25) .add(tweenSelector, 2.25) .add(tweenLogo, 2.25); return tl; } var master = new TimelineLite(); master.add(buildStart(), "start"); Then, you can create a function for each section of your animation, and just have that function spit back a timeline that you nest wherever you want into a master timeline. Once you do that a few times, it's a game-changer for your workflow. You can then take entire chunks and move them around, and isolate individual chunks in their own intuitively-named functions, etc.

erikb, we really try to make everything "just work" in the most intuitive way across all our products but the behavior you anticipated here would have some negative consequences if we made that all "automatic", like: It would force a backwards dependency from ThrowPropsPlugin onto Draggable, but I think that's inappropriate. In other words, lots of people might want to use ThrowPropsPlugin on its own, completely detached from anything Draggable-related. But if we made ThrowPropsPlugin automagically check if the target is also Draggable and then reach into Draggable and enforce its logic, it suddenly creates that dependency and requires loading Draggable too (even if it's not necessary in their project). Doing so assumes that the user WANTS all that Draggable logic applied, but I don't think that's a solid assumption to always make. In other words, guys like Blake to all kinds of crazy innovative stuff with the tools and probably don't want to have their hands tied in that way - they should be able to create a ThrowPropsPlugin that isn't shackled by the logic that Draggable was imposing on manual dragging. It actually seems a little counter-intuitive in some ways, like you have a ThrowPropsPlugin tween that defines both "x" and "y" velocities (and bounds), but it sounds like you're expecting it to just completely ignore the "x" aspect. If it's defined in a tween, it'd probably feel weird to most people to have it ignored because there's some other Draggable instance somewhere that has different logic applied. We really try not to make too many assumptions about how people code their stuff. We don't want to overreach in the name of "convenience". It's a fine line to walk sometimes. We generally air on the side of caution because GSAP caters to advanced animators who do aggressive stuff and need robust, extremely flexible solutions. We definitely appreciate hearing suggestions, though. We're always striving to make things better and there's surely room to improve.

A tween's playhead is always determined by its parent timeline's. In your codepen, you're reversing the tween while it's inside a timeline whose playhead is already at its end, thus when you reverse direction of the tween, it will immediately render at its starting state. That's exactly how it's supposed to work. Otherwise, the state of the timeline wouldn't be correct. I'm curious - why are you using a timeline at all? And why are you trying to reverse only 1 tween inside of a timeline instead of reversing the whole timeline? Perhaps if you help us understand your goal, we can offer some solutions.

Sure, all animation classes share a common reverse() method (as well as most other basic methods for control, like pause(), resume(), timeScale(), seek(), etc.). var tween = TweenMax.to(...); //then later... tween.reverse(); Note that when you reverse(), it just makes the playhead go backward toward the start from wherever it is currently. So if you call reverse() when the tween has already played for 1.25 seconds, it will then take 1.25 seconds to reach the beginning again. If you want it to jump to the end and play backward, you can call tween.progress(1).reverse(). Does that help?

Ah, I see what you're trying to do. Hm. That's totally possible but non-trivial. You have to calculate the lengths of all the segments, figure out which one the current progress lands on, then subdivide that segment at that particular progress point so that you can then do all your drawing of the segments accurately. That's not something BezierPlugin provides for you. Even if it gave you the current segment a, b, c, and d values, it doesn't really solve your problem. Blake might have something up his sleeve (he's always great at this stuff), but if not and you still need help, feel free to contact us about hiring us on a consulting basis. I've been neck-deep in this type of stuff lately for CustomEase: I really wish I had a super-easy solution for you. Oh, and by the way, I noticed you used MorphSVGPlugin.pathDataToBezier() and then fed that in as type:"thru" which won't really work properly (it should be type:"cubic"). Side note: if you want to get all the a/b/c/d values that result from the "thru", you can get those directly via BezierPlugin.bezierThrough(). http://greensock.com/docs/#/HTML5/GSAP/Plugins/BezierPlugin/bezierThrough/

Sorry for being late for the party I took a peek and I see why it'd seem a little confusing but from what I can tell, everything is working exactly as expected. Let me explain... Like Carl said, the timeline has no idea what you intend to do inside of your onComplete callback - it just calls the function. You happen to be changing the x/left properties in there which is fine, but it isn't as if it then inserts those values into the timeline. When the playhead changes position in a timeline, it must make sure that all of its child tweens/animations are in the proper state. In your case, you've got a tween that animates x to 700. So when you resume() your timeline and the playhead starts moving again, it says "hey, tween, make sure you render at the end properly which means...x:700". If we didn't do that, the state in a timeline could get out-of-whack. When you overwrite:"all", it finds all of the other tweens of that same element and kills them. In your case, that means it'd find that x:700 tween and nuke it. Therefore, when the timeline starts moving again and renders its state, x won't get set to 700 because that tween was killed (overwritten). Make more sense now? If you have any suggestions for more intuitive behavior, I'm all ears. As far as I can tell, everything is working properly.

I'm still a little fuzzy on what the problem is that you're describing (like exactly which two calls have a gap between them and how to reproduce that), but this is where the actual pause() occurs in TimelineLite (inside TweenMax): https://github.com/greensock/GreenSock-JS/blob/master/src/uncompressed/TweenMax.js#L1094 Is that what you're looking for? It happens right before that "tween" (pause) gets rendered which is when the callback would get fired. From what I can tell, it's exactly where it should be. Might the issue be related to a flaw in LG WebOS 2 and how/when it triggers the requestAnimationFrame()? (Just a guess). Or are you saying that you think there's a logic flaw in GSAP itself that's causing things to fire at the wrong time?

Oh, and one more side note: there's a gap between the "paused" and "unpaused" logs in your codepen simply because you're logging "paused" immediately when you're adding the pause to the timeline rather than when it actually happens. So since you're placing it 1 second in the future, the callback won't get called until then. Seems to work as expected.

Hi @NamelessGhoul. Welcome to the forums. Very happy to hear about the positive reputation of this community. Puts a smile on my face. Anyway, about your question, I'm also a bit confused because I'm not quite sure if you're saying that you think the callback that you've got in the actual addPause() method isn't getting called immediately, or that you're having trouble with your own code and ensuring that a different function is called on the very next requestAnimationFrame tick. Can you clarify? It looks like your code would wait for 2 requestAnimationFrame cycles, so perhaps that's the problem? In other words, inside your afterRepaint() function, you've got a requestAnimationFrame() that will wait for the NEXT time the browser refreshes the screen, at which time you've got ANOTHER requestAnimationFrame() inside _startRender() that will wait for another browser refresh, and finally call your callback. Perhaps you weren't aware that requestAnimationFrame() would wait for the next refresh (thus delay things)? Totally guessing here. I may have completely misunderstood what you're asking or what the perceived problem is. Oh, and minor note: your codepen demo is not using the latest version of GSAP. I'd recommend linking to the 1.19.0 version on the CDN directly (not the "latest" which, unfortunately, our CDN provider refused to update after 1.18.0).

Welcome to the forums, martifenosa. Hm, it's difficult to troubleshot with all the other code in there on a live site, but I did notice that the site is using a much older version of GSAP (1.15.1). Have you tried updating to 1.19.0? Happy tweening!

Thanks for the suggestion, venn! Yeah, I think it makes a lot of sense to leverage GSAP in a prototyping tool. The challenge for us is keeping our limited resources focused on the most important things. It's so easy to get distracted and chase various ideas (I have a TON of ideas). Building a GUI is a very, very different skillset and a lot of time. Several other 3rd parties have used GSAP in their GUI tools, and we think that's probably the best path forward at this point. Hopefully tools like framerjs will allow exporting to GSAP code at some point. Thanks again for the suggestion. Stuff like this is always welcome in the forums, by the way.

The main (entry) JS file that the "gsap" package points to is TweenMax.js but since Draggable isn't part of TweenMax, it wouldn't work to just import from there. Sorry. We do plan to restructure things at some point, but we're not there yet (doing so isn't trivial). In the mean time, you should be able to just import the Draggable file directly (not from "gsap") or set up an alias in your config file that associates "Draggable" to that file path. Let us know if you need help with that.

Very cool animation. Slick. I don't have a lot of time to research at the moment, but two quick things come to mind: You might want to read the posts here: http://greensock.com/forums/topic/13681-svg-gotchas/?p=65150. Blake's comment was related to masks, so it may not be relevant with clipping paths, but perhaps you'll find something there that's worth trying. I noticed that you're not using DrawSVGPlugin, but instead you're directly animating the strokeDashoffset which is totally fine but I remember running into some bugs/problems in Microsoft browsers and implementing workarounds inside of DrawSVGPlugin. In other words, it might behoove you to try DrawSVGPlugin and see if it resolves the issue for you. Try it out on codepen for free (any of the bonus plugins) - here are the URLs: http://codepen.io/GreenSock/full/OPqpRJ/ Let us know if that helps at all.

I'm a little confused - I thought we were talking about pinch-zooming and multi-touch. Your last comment seems to be talking about scrolling. Did I miss something? And by the way, the behavior you described is exactly what the autoScroll feature does already in Draggable (if I understood you correctly)

Hm, that's odd that you don't have access to the config file, but I can think of two other options: Just use a <script> tag for the GSAP-related stuff. You could load the files from the CDN and get the benefits of caching too. -OR- delete the 4th line from the bottom of ScrollToPlugin where it says require("../TweenLite.js"); Do either of those work for you?

My guess is that if you're doing a slow panning effect, perhaps you're using "left" or "top" properties, or maybe backgroundPosition? Browsers always snap those to whole pixel values (that's not a GSAP thing, it's a browser thing), so it can cause things to look jerky. It's always best to animate transforms like "x" or "y", as those deliver sub-pixel rendering. It's pretty tough to troubleshoot blind, though, so if you could provide a codepen demo that'd be super helpful. Happy tweening!

I think I figured out a workaround which you can preview here in the beta version of the upcoming Draggable release (uncompressed): https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js Does that work better for you? Seems to fix the demo you provided.

Yeah, I just did more testing and confirmed that in order to disable the native touch-scrolling (which is necessary, otherwise the entire page will move when you try touch-dragging the Draggable), preventDefault() must be called on the touchstart event, but doing so ALSO prevents native pinch-zooming. So the way touch events are implemented in the browser, it's forcing us to choose one or the other. Can't do both. Pretty frustrating, I know. If anyone knows of a workaround, please let us know. For now, it looks like it's simply impossible.

I wish there was a way to just delay the preventDefault() call by 200-300ms but that's just impossible because the browser needs an answer IMMEDIATELY about what it's supposed to do. In other words, if we don't give that answer right away, it'll impose the default behavior which is NOT what you want when dragging. I'll try to poke around and see if I can find any other viable solutions, but it's not looking great at the moment.

From what I can tell, that's not a bug at all - it's just that the code in that demo makes some faulty assumptions. First, it's using jQuery.offset(), so the top/left positioning is based on the PAGE position, but remember that CSS top/left is always relative to the offsetParent which is the closest parent that has position:absolute or position:relative. In this case, each word is wrapped in a <div> that has position:relative. So that's throwing things off. Even if you switch to using jQuery.position(), it looks like there's a bug in jQuery that's not returning the values properly. You could just set position:"absolute" on your SplitText which will do all that work for you. This would simplify your code too, and it's much more accurate. But frankly, I think it's a big mistake to be animating the top/left properties and fontSize. You'll get significantly better performance (and your code would be simpler) if you just animate x/y (transforms) which don't affect layout. Basically, it's much cheaper for the browser to make changes to transforms rather than top/left. Does that clear things up? Oh, and thanks so much for the kind words! We always love to hear from ex-Flashers who made the jump to HTML5 and used GSAP to ease their transition. Very happy to hear that it made things smoother for you. And I totally agree about the community around here. We're very blessed to have such good people who are eager to help and never make someone feel stupid. Cheers!

I believe I fixed that one case now too that caused it to break previously. It'd only happen if you split by only chars (not words or lines). But again, it should be all patched up now from what I can tell but please hammer away at it and tell me if you can break it. I updated the codepen URL as well as the "real" file in the members-only download zip. Have fun!

Thanks Jonathan. The problem isn't sensing when there's a multi-touch, though. That's pretty trivial. It's more about the fact that on the FIRST touch, we preventDefault() on the event which kinda tells the browser "don't do what you'd normally do with this touch, like drag-scrolling, pinch-zooming, etc.". So it's more of an issue with properly handling preventDefault(), but you can't go back in time and say "oh, I know I told you to preventDefault() on that last touch, but I was just kidding - can you now ignore that request because there's another touch that happened?" Tricky, I know. Not sure there's a solution.