Change appearance of scroll speed without affecting when element is not in viewport

[calsal8]

@calsal8 ya I think you misunderstand how the library is designed to work, or I don't understand the problem. The offsets are used to give an element the varying appearance of scroll speed. Increase the offsets the more the dramatic the effect.

Not sure if the question is meant to relate to v2 since you're referencing the v1 API. If you're having trouble with implementation open a new ticket and I can help you out there, as I'd like this ticket to be used for discussing v2. Thanks!

@jscottsmith Sorry if I posted in the wrong place, I thought my question was related to a new feature that could be included in V2. But let's clarify the question here first. Maybe the library is not designed to work as I would hope. Either way I find it very useful.

When I change the offsets the appearance of scroll speed change, just as you wrote. I've used offsetYMin={-1000} to achieve the fast scroll speed that I want. But that also keeps affecting the style animation when the element is 1000% outside the viewport. In my case I want the fast scroll speed but, for performance reasons, I don't want it to change the style when it's far outside the viewport. I'm thinking that could be solved with a multiplier that multiplies the scroll speed with a given number. What are your thoughts?

[calsal8]

@jscottsmith I can open a new pull request to quickly show you what I mean?

[jscottsmith]

@calsal8 no worries, and thanks for opening this issue! Ya I just didn't want a bunch back and forth trying to figure out what you are after. Definitely open to changes in v2 if they improve the library.

But that also keeps affecting the style animation when the element is 1000% outside the viewport.

This shouldn't happen. Can you share your particular setup with me? A repo or live site would be best for me to understand what you're trying to do and what the problem is.

I can open a new pull request to quickly show you what I mean?

Absolutely.

[calsal8]

This shouldn't happen. Can you share your particular setup with me?

@jscottsmith Okay, maybe that's because my moving element is greater in height than it's container? Unfortunately the setup is private for a company I'm working with but I'll try to explain it here. The parent container gets it height from some text elements and has overflow: hidden, the parallax component inside is position: absolute; height: 100%; width: 100%, which has many (about 15-20) SVGs as children. These SVGs are also position: absolute and varies from top: 10% to top: 300% to spread out. Five of the first SVGs show from start. When the user scroll down, the parallax container moves up and the SVGs underneath starts to show.

Maybe your library is not designed for this kind of setup? My solution would be to add a multiplier that multiplies offsets.y.value in ParallaxController._setParallaxStyles by a given number and sets that calculation in translate3d. I'll open a PR for you to look at. If you don't see it useful just let me know and abort the PR. Thanks for reading my request!

[jscottsmith]

Ya, I think the best way for me would be to see an example. A simple setup that reproduces the behavior would be ideal -- doesn't have to be pretty. Hard to say if it's a bug or if it's a use case that should be a supported otherwise without seeing the implementation.

[calsal8]

Yeah I get that. I wouldn't say it's a bug, just a different use case. I've added a simple setup on Codepen which is not pretty, but I think it shows what I'm after.

In the example there are five SVGs positioned under each other and the third one is half visible when the user has scrolled down to the point where the section is about to leave the viewport. My goal is to have the fifth SVG visible at that point. If I could multiply the second parameter in translate3d by a certain number it would be possible. Let me hear your thoughts :)

[jscottsmith]

Ok, I think I'm beginning to see the issue you are running in to. It revolves around the way that I'm calculating the percentage that an the element has moved through the viewport and the bounds that the element occupies. With very large offsets the bounds increases dramatically and the effect of offsets almost becomes negligible. You can actually see these "bounds" in v2, check the DOM for the "parallax-bounds" class. Technically, I'm considering the element "in view" even though it's clearly not because the bounds have increased so dramatically.

Check out this demo and increase the offsets to 1000 or so. Then notice how it's not a linear distribution. That illustrates the problem you are having, I think.

I've wondered if this would be problematic but then thought that it would not be a typical use case. So now I'm wondering if I should re-think how I calculate the percentages and not base them on the bounds but rather the original element size. There are problems going with that direction though, as it will be more complicated to determine when the element is actually "in view". Or maybe there's another way that I'm not considering.

Back to your original proposal -- I think a multiplier would work (and please submit a PR if you have time so I have a record of a possible solution) but it feels like a bandaid and will complicate the prop API which I'd like to keep as simple as possible, especially for v2.

I'll keep thinking about it. If you have other proposals I'd really be interested in hearing them. Thanks!

[yuliwna1]

Thank you for this great library! How could I disable all parallax effects on mobile devices though?

[jscottsmith]

Thanks @yuliwna1, this issue should help you out with that: #38

[yuliwna1]

Thanks a lot!

[jscottsmith]

fixed this in v2. See #47