cmal

Thank you @GreenSock! I've tested this both in CodePen and in my actual project implementation (which is much more complicated in terms of animation) and this worked perfectly in both. The only thing I ran into is that I'm using Typescript and TS complains that the "snapTo" method does not accept an argument of "self" in snapTo: (progress: number, self: GSAPTimeline) …but that is a fairly minor thing. Thank you so much for investigating this and helping figure out a solution.

I've been working on a GSAP animation using ScrollTrigger + SplitText to make a timeline animation. The animation consists of a handful of sentences that animate in one after the other, with a timeline label existing at the start of each sentence. I've noticed that when setting snap.snapTo to "labels" or "labelsDirectional" that the position the timeline snaps to will very often not be the exact label position, but a couple frames before or after the label, resulting in characters that should be visible (e.g. the period at the end of a sentence) being invisible, or characters that shouldn't be visible (the first letter of the next sentence) being visible. You can see this either in the linked CodePen or in the attached video where I added visual click indicators to point out the places where this is happening. I'm pretty sure I know the reason why this is happening: browser scroll position has a finite amount of precision because scroll position is set in whole pixel increments, while the exact position of a label within a timeline may be an infinitely precise progress decimal, and so there's no way to represent every possible amount of progress using scroll. But regardless of the reason, this presents a pretty significant obstacle for snapping to label positions when the exact animation state at that position needs to be precise, such as my case. This inability to snap precisely to a label also creates issues when using other label-related functionality, such as .previousLabel() or .currentLabel() on the timeline, which will often be different from the label that you are supposedly snapped to. I haven't been able to find a way to work around this, and would really appreciate any help pointing me in the best direction to handle this. It also feels like there should probably be some sort of built-in way to address this, even if is a one-off scroll trigger parameter like "forceSnap" or something which ensures that label positions map cleanly to the scroll even if that would mean fudging a couple of frames within the timeline to ensure that that happens. I can't think of many situations where I'd be wanting to snap a timeline to a label and would be okay with that snap position being off by a frame or two in either direction. gsap-split-text-scroll-trigger-timeline-snap-rounding.mp4

@Thomas Günther Thank you so much! That is exactly the solution I was looking for and works great. Really saved me some digging!

I found a Codepen created by Greensock that exactly matches the behavior I'm looking for on a project, using Flip with onEnter and onLeave to filter items very smoothly. The only problem is that any DOM content that follows the parent of the Flipping elements will be incorrectly positioned during the Flip, which causes some unsightly overlap. I'm not exactly sure how to remedy this, or even if it can be remedied using this approach. Any suggestions? Here is a Codepen demonstrating the issue. The only change made to the original Codepen example is the addition of a sibling container to demonstrate the overlap clearly. Thank you!

Thumbs up for increment

For what its worth… When I was first trying things out, I thought that maybe what I was looking for was actually supported but undocumented, so the first thing I did was try both of the following: snap({value: 500, radius: 100}); snap({values: 500, radius: 100}); That being said, if I was coming in totally fresh I'm not sure I'd look at snap({value: 500, radius: 100}) and assume that meant that it would snap to any increment of 500 – I'd probably assume it meant that it would only snap to a value of 500 and only if it was within 100 of it (400 – 600). I think this is probably a much bigger API change and therefore rules it out, but this was the most intuitive syntax to me when I was first thinking about this: snap(500, { radius: 100}); It looks similar to the default usage of the function, which uses incrementing values, so it is familiar in that regard, and it treats the radius as an option that you just mix into the function. I think for that to work you'd have to significantly change the API so that the first parameter could alternatively be an array, which would make the function consistent when used with either single incrementing values or an array of values. But that's a pretty big change.

While snap is obviously a lot shorter, I don't think it communicates that the value repeats as clearly as increment. And on a much more subjective level, seeing the word snap twice that close to each other in the same function feels weird.

I like increment.

Been getting a lot of use out the new GSAP utils and I love them. I did run into a use-case with the snap() util that doesn't seem to be covered, and it seems like something that would be broadly useful. So consider this a feature request. I'd like the ability to use the radius parameter without needing to provide an array of values. For instance: gsap.utils.snap({ value: 500, radius: 100}, x); For examples of expected behavior: If x is 400, it would snap to the closest increment of 500, which is 500 If x is 300, it wouldn't snap to any value, because it isn't within the radius (100) of any increment of 500 If x is 950, it would snap to the closest increment of 500, which is 1000 Perhaps this was omitted for performance reasons or something similar, but this is how I'd most likely use the radius property the majority of the time if it was an option. Thanks!

Actually, appears I was able to resolve this just by importing DrawSVGPlugin.js from the commonjs-flat directory instead of uncompressed.

Same issue here. Using npm for all non-Club Greensock imports.

http://codepen.io/anon/pen/bjKED

I feel like I'm still not really getting how to accomplish the timing I'm after with labels and offsets. Take the following example: new TimelineLite() .to(myElement, 6, { x: 200 }); .addlabel('otherStuff+=3') .to(anotherElement, 3, {rotation: 360}, 'otherStuff') .to(myElement, 3, {y: 60}, 'otherStuff') .to(thirdElement, 3, {rotation: -360}, 'otherStuff') Here's what I would expect to happen here: myElement changes x position for 6 seconds 3 seconds pass The remaining 3 tweens all happen at the same time (coinciding with the location of the 'otherStuff' label) But this isn't what happens. How can I accomplish something like this?

I'm not opposed to storing the original value on the element, but I think where that could become cumbersome is if I'm using something like staggerTo() to tween lots of different paths at once. In that case, is there a way I can grab that .originalValue off of each path as I'm staggering through it?

After performing a bunch of different tweens on an element, is there a shortcut to tween back to the original value? Here's an example… var myPath = document.getElementsByTagName('path')[0] var strokeLength = path.getTotalLength(); myPath.style.strokeDashArray = strokeLength; myPath.style.strokeDashOffset = strokeLength; var tl = new TimelineLite .to(myPath.style, 1, { strokeDashoffset: 0 } ) .to(myPath.style, 1, { // Ideally, I could return to the pre-tweened value here // without needing to look it up again (or store it in some other way) strokeDashoffset: X } )