Webit Interactive

@GreenSock There does not seem a way to put it so that it actually scrolls up rather than down as shown in the initial use case here: Using "clamp(0.5)" versus "clamp(-0.5)" versus "clamp(1.5)" versus "clamp(-1.5)" you can compare the issue in your forked codepen. https://codepen.io/mpare/pen/XWYKOMM I also feel like there must be something with the calculations for the translating. I may have things backwards for the way ScrollSmoother uses it for its logic, but shouldn't a positive data-speed like "2" make the element go up faster rather than down faster? Since we are scrolling down, an element with a higher data-speed should behave as though every pixel scrolled down increases it's speed going out from the top and a value below 1 should mean that it scrolls slower than than a normal item and therefore stays in the viewport longer. However, the logic can also be reversed and used as the way it is at the moment, but should allow for elements to also scroll up faster rather than scrolling down.

@GreenSock Amazing work on the footer data-speed functionality! That is the behavior we are looking for I've re-used your codepen for an easy example of the logic on ScrollTrigger. As you can see on the first fold, the same logic applies for the animation that is already partially completed on a scrollTop of 0. When we get to the top of the page (or load initially), the scale animation is already at ~1.335 for a 1.5 scale animation. Ideally, we would be able to apply the same logic where the animation is at a progress of 0 (0%) when we are at the top of the page and progress to 1 (100%) upon scrolling. https://codepen.io/mpare/pen/jOeONdb

@GreenSock That is exactly what we are looking for and I'm sure people would benefit from this behavior for their banner animations! Having to simply add "+=" to the value makes it simple and easy for usage. However, I'm wondering if that would work for a situation like a footer where the element should reach its initial state when we reach the bottom of page? Perhaps using "-=0.5" for that situation could work? As it is the same logic, except backwards. Also, if there was an option we could pass to ScrollTrigger as well to have the same behaviour for those scrub animations, that would be the icing on the cake! For example, if we add a 1.5 zoom scrub effect on the backround-image of our banner, it would already start with a 1.XX zoom value since it's completely in the viewport with a scrollTop of zero. Do you think that is something that would be possible?

That is exactly what I wish to have as default behaviour! I'm guessing by the added JS code to manipulate the data-speed that there is no current way to have it this way as a default behaviour for ScrollTrigger / Data-speed animations without having to loop through the animations and manipulate the start values?

I have made a codepen with pieces of our plugin as an example of the behaviour: https://codepen.io/mpare/pen/XWYKOMM

Hello! We can use the base codepen in the docs to use as an example: https://codepen.io/snorkltv/pen/vYjrKWX As you can see, since the different data-speed offset is calculated based on the viewport (same with ScrollTrigger animations), the boxes are already offset even with a scrollTop of 0 instead of having their initial position on a scrollTop = 0 and then being animated on the scroll. The behaviour that we wish to replicate without having to code exceptions would be similar to what we currently have which is that, even with different data-speed for each letter in a word, the word is still all lined up on a scrollTop = and then would scroll at different speed rather than having proportional offset already being applied on the elements. In my screenshots above, the first one is when we are at a scrollTop of 0, and the second one is when we start to scroll. As you can see, the letters have a different scroll speed, but they are still lined up together to form when at the top of the page. Ref: Before: https://gyazo.com/658ec851f163d3382d96f9519bf26782 After: https://gyazo.com/699a0ae8a567f4aa08ccda0c150e933e

Hello, I was wondering if there was a simple way to make it so elements are all lined up with a scrollTop of 0 and then have their different scroll adjusted upon scrolling? It seems that with ScrollTrigger animations and ScrollSmoother's data-speed, the offset calculated from its position in the viewport right away based on the start/end values despite where the scroll is located and therefore undesirable behaviour. I also believe this would create an issue with anything animated in the footer as the same logic would apply which is that elements will never be able to reach their "center" and therefore always be offset as opposed to arriving at their original state upon reaching the bottom of the page. (I'm aware that in most scenarios, the footer will not be animated in such a way, but I'm stating the two cases as only problematic examples.) Expected behaviour: Before: https://gyazo.com/658ec851f163d3382d96f9519bf26782 After: https://gyazo.com/699a0ae8a567f4aa08ccda0c150e933e We've had our own version of a "data-speed" scroll and since we've been using GSAP for everything else, we want to shift over to ScrollSmoother since we believe there will be a gain in performance and will allow us better scoping and usability of the animations. Thank you

UPDATE: The issue is fixed by adding "display: inline-block" to the <em> tag. *shrugs* Hello @GreenSock. I have converted part of the block to codepen for testing. I have found the problem, though the logic behind it cannot be explained. Basically, the secondary font used for the <em> tag makes it break. I am eager to know if you would have any ideas as to why! Hehe Here is the codepen: https://codepen.io/mpare/pen/XWYKOMM

There seems to be an issue with the <em> tag and the SplitText plugin in the GSAP version below. As you can see in the screenshots, it breaks all <em> tags into new lines, but it does seem to respect the <strong> tags. GSAP Business v3.11.3 Expected (and base text) behaviour: https://gyazo.com/551114c1711155482da296989ed33847 Split (lines) behaviour: https://gyazo.com/a8aa6d94effc0856fc7776ea051cea85 <strong> is respected: https://gyazo.com/907bf5caa5ccb04ae6e9ac5996fe63e2 Is it a known issue? Thank you