data-speed="auto" variable parallax direction

[andrewCodes]

Hi. I've been working with ScrollSmoother, using data-speed="auto" on images. I noticed some images were going with the natural scroll of the site whereas others were going against it (i.e. as I scroll down, the images appear to move up and vice versa). I couldn't work out what was going on and assumed I must have done something wrong somewhere. In an attempt to remove as much code as possible, I grabbed the example codepen (as linked here) and noticed it does exactly the same thing. The first image and the final two images go the "wrong" direction (i.e. against the scroll) whilst the others go with the scroll. The three that go the "wrong" direction are larger and this seems to be the cause.

 

It is the height in relation to the viewport that seems to cause the issue rather than the actual height of the image. For example if an image has a height of 500px and is on a viewport with a height of 550px, the parallax will be in the wrong direction but if I extend the window so the viewport is, say, 1000px then the parallax with be the right direction.

 

Having a page with parallax going in opposite directions seems odd. As does the direction of the parallax of a specific image being decided based on the height of the viewport. I can get around this by using a number rather than auto as the data-speed value but this seems to rather defeat the purpose of auto. I have to say I don't quite understand the technicalities of why this is what happens when using auto. Is this by design or is it a bug? It seems that if I want to ensure parallax images always go with the direction of scroll I cannot use the auto feature. Is that correct? 

See the Pen PoOpobM by GreenSock (@GreenSock) on CodePen

[GreenSock]

When you set the data-speed to "auto", that basically just means that ScrollSmoother will look at where you INITIALLY have the image positioned inside its container, and calculate which direction there's room to move it, and it'll go in that direction. So, for example, if you initially align the element so that its bottom edge aligns with its container's bottom edge and there's extra image bleeding beyond the top of the container, then data-speed="auto" will end up moving the image DOWN. 

 

So you should be able to control the direction by simply setting things up initially in the correct way. 

[andrewCodes]

That's what I assumed would be the case – direction would be based on where the overflowing part of the image is. However, as shown in your demo that is not what actually happens when using auto as yourspeed value. All the images in the demo have bottom: 0 applied yet are not all going in the same direction. If that alignment was what defined the direction of the parallax when using auto all of those should go in the same direction but they don't. Outside of the codepen demo, this inconsistent result can be seen at around 7:50 in opening video on the ScrollSmoother page of the gsap docs – the image that enters the viewport after the full width image of the trees is going in the opposite direction. Further evidence of auto not behaving as expected is that in the gsap codepen demo I linked to in my opening post, if you change the speed value on line 9 of the JavaScript tab from auto to, for example, .5 all the images parallax in the same direction with no changes made anywhere else. These three pieces of evidence seem to show that the alignment of the images does not dictate the direction of the parallax when using auto as the value for speed.

[GreenSock]

Hm, perhaps I'm misunderstanding you or I'm not explaining things well, but here's a fork that illustrates a little better: 

See the Pen xxNPGMx by GreenSock (@GreenSock) on CodePen

 

From what I can tell, everything is working perfectly. Notice that in every case, it is indeed moving the image from top to bottom inside the container(s). I think what might be confusing you is that based on the height of the image/container/viewport, they move at different speeds, thus sometimes it's slower than the scrolling speed of the overall page, and other times it's faster, thus they APPEAR to be going in different directions but that's only because of the relative speed of the page scrolling speed. 

 

Right? 

[andrewCodes]

I think the image with the car on the road is probably the easiest to look at as the car acts as a nice point of reference. Scroll up and the car moves downwards in the viewport, scroll down and it moves up. To illustrate it more clearly I've added a dividing line across the viewport and set the opacity of all other image containers to 0 to remove any distractions.

See the Pen abrVWRe by andrewCodepens (@andrewCodepens) on CodePen

 

[GreenSock]

Yes, I'm struggling to understand why you think that behavior is incorrect. It's working precisely how I'd expect. 🤔

 

The image is initially set up such that the extra chunk of the image is bleeding out the top of its container, thus ScrollSmoother does all the necessary calculations to move the image DOWN as the container moves upward through the viewport. 

 

Am I missing something? 

[andrewCodes]

What I believe is incorrect is the inconsistency in direction. To highlight the inconsistency I have shown a second image in this updated codepen – the person on the skateboard. As you can see, the skateboarder moves with the scroll and the car moves against the scroll. All images are set to bottom: 0 with speed set to auto and so should – or at least I would have thought should – go in the same direction yet they do not.

 

See the Pen pomdqXP by andrewCodepens (@andrewCodepens) on CodePen

 

[GreenSock]

Isn't that what I already explained in my second reply?: 

On 6/12/2024 at 1:34 PM, GreenSock said:

I think what might be confusing you is that based on the height of the image/container/viewport, they move at different speeds, thus sometimes it's slower than the scrolling speed of the overall page, and other times it's faster, thus they APPEAR to be going in different directions but that's only because of the relative speed of the page scrolling speed. 

 

From what I can tell, it's all working perfectly. In order for it to work the way I think you're expecting, it would have to NOT allow the image to move the full distance inside the container, but only sometimes (when the image is adequately tall compared to the container). See what I mean? 

 

For example, let's say you've got an image that's only 100px taller than its container, and your viewport is 1000px tall. If the container is 500px, that means the image would move a total of 100px over the course of scrolling 1500px (the top of the container hits the bottom of the screen, then must travel 1000px, the height of the viewport, plus another 500px to get fully out of the viewport). So the image would be moving 0.06667 pixels in the opposite direction of scroll for every 1 pixel of scrolling. 

 

But let's say your image is 2500px taller than its container instead of 100px! Now, it must move 2500px over the course of 1500px of scroll. So now, it'd move the image 1.6667 pixels in the opposite direction for every 1 pixel of scroll! Therefore it'll look like it's going FASTER down than the whole page is moving up with scrolling (hence it appears to go backwards). None of that is incorrect behavior. It's precisely what the math would dictate. 

 

And by the way, it'd technically move more than what I mentioned above because "auto" attempts to move it all the way across the container, so it'd include that distance too, but I was trying to keep it simpler to visualize. It's the same dynamic at play either way. 

[andrewCodes]

I'm not 100% sure whether that's what you already explained. Whether or not that's what you already explained and whatever the technicalities, to a user scrolling in a particular direction, the skateboarder image moves with the scroll whilst the car image moves against it – as shown in my previous codepen.

 

Whilst I appreciate the result of using auto may be what the maths dictates, it seems a strange decision – perhaps only to me – to make the maths dictate that images may appear to go in opposite directions. I can't really see this would ever be acceptable to designers / product managers and therefore by extension, to developers. I can only assume I'm wrong and that most people do not mind what direction images parallax nor whether the direction is consistent across a page.

 

Given the result is what the maths dictates I guess the answers to my original questions are as follows:

 

• Is this by design or is it a bug?
  • It is by design.
• It seems that if I want to ensure parallax images always go with the direction of scroll I cannot use the auto feature. Is that correct? 
  • Correct – you cannot use auto if you to ensure images always appear to go with the direction of the scroll.

Thanks for your responses. From a personal perspective, it is a little disappointing as this confirms auto is not something I can make use of as I absolutely need to ensure the direction images appear to move is consistent. Whilst I am personally surprised that the maths has been written as it has I assume my expectation of consistency is not the expectation others have. It's good to have everything cleared up though so thanks for that and for all the good work making GSAP. 🙂

[GreenSock]

Yeah, I think I understand where you're coming from, but here's the key question: if I made it work the way you were expecting, where are the limits exactly and wouldn't it actually be considered BROKEN by many users? 

 

The current behavior (which is what we basically promise in the docs) is that it'll move the element as far as possible such that it reveals ALL of the image/element eventually. So for example, let's say that requires a movement of 500px in one particular case. But doing so might (depending on the height of the viewport and the container) make it move at a slower rate than the container element is scrolling (so it appears to be moving the opposite direction). You're suggesting that instead of moving 500px, ScrollSmoother would figure out that it's slower than the rate of scrolling and therefore adjusts it to move LESS than 500px, right? So how much slower? Perhaps moving at 400px would make it actually stay completely still in the container, so then should it move 399px such that it's only moving at the smallest possible rate? Should it go a little faster than that? Where exactly would we draw the line? How are we supposed to know what the developer wants? Would they need to somehow provide a pixels-per-second rate? And even if we allowed that, it means that the image would NEVER show the entire image. If it has 500px of gap, but we only move 399px, that means 101px never gets seen. A lot of people would think that's broken. 

 

So the very nature of "auto" is such that it reveals the whole image, period. If you want it to move at a certain speed, you shouldn't choose "auto" - you should specify a speed. See what I mean? 

[andrewCodes]

I guess ultimately things like auto are always going to be opinionated and so are not always going to do / be what everyone would make them do / be.

 

The opinionated decision I would have made with regards to the spec of what auto does – if I was actually capable of making such a thing for myself –  is that it would always ensure the parallax effect made images appear to scroll with the direction of the page just more slowly (not necessarily all the same speed as then you may as well just use a number). How that would be achieved mathematically I don't have the faintest idea (which is why I use something someone else has made) and what the exact limits would be would require more thought and experimentation.

 

Whether or not people would consider my hypothetical spec broken or not I really can't say. No doubt some people would whilst for others it would be what they were expecting. I really have no idea whether I'm in the minority or not but I presume the spec for auto was discussed internally within the GSAP team, the collective opinion was formed as to what it should do and then the coding starts to implement the spec. I would certainly have argued for the spec to be different to the one decided upon but I would have happily been over-ruled. So long as the implementation of an opinionated spec works – which it does – really that is what matters. 

I had read the docs with a particular assumption based on my opinion / experience of what parallax movement is generally used for (i.e. giving depth to a page by making images appear to move more slowly). As such I clearly hadn't taken what was written in the right way.

As I've alluded to though, just because I would have written the spec for auto differently does not mean I think the spec is wrong. On matters of opinion there really is no right and wrong. An opinionated spec is what it is and if it works for you, great, and if it doesn't, don't use the feature / tool. I certainly don't think anything less of the feature just because it doesn't do what I would have made it do – that would be very arrogant. It's a great feature to have included and I'm sure it's exactly what a great many people want and expect... I am just not one of those people, which is fine. I will – and am – still going to use speed / data-speed, I just won't use auto as the value of that property. Problem solved 🙂

[Cassie]

All good! Sounds like speed is the right fit here.

And yeah, in terms of "why" this is like this, 'auto' in this case just means "automatically shift the image within it's container in the direction of the largest gap (up or down)."

It's solving the most common challenge we saw people having with parallax images, where someone wants to move an image within a container without it moving outside of the bounds of the parent. This demo shows this, with speed it's hard to know *what* speed is correct, and you can end up moving the image too far and cropping the image off

 

See the Pen bGyLmEG?editors=0100 by GreenSock (@GreenSock) on CodePen

So it's certainly possible to get consistent results but you have to ensure that all your images are the same ratio and positioned the same in the CSS and in the same ratio container. That's where the control lies.

 

 

 

 

 

[andrewCodes]

Absolutely... that challenge was exactly why I reached for auto in the first instance. I'd just incorrectly assumed auto solved the challenge in a different way. Unfortunately I can't ensure all the images / containers are the same ratio as I just build designs I'm given. It's not a big deal though... really I just needed to know whether the results I got with auto were expected or not.

Awesome to hear from you by the way, Cassie... been reading and watching your stuff online for a long time – feel like I've now met one of my coding heroes! Big thanks to both you and the unnamed admin I was talking to beforehand. 🙂

[Cassie]

That was Jack, (the person who wrote the GSAP library.)  So definitely more of a coding hero than me! 😂 Thanks for the kind words though. 💚

[andrewCodes]

Thanks to you too then, Jack 🙂 Awesome library you've made and the help provided by you and your team in these forums is second to none  👏