I promise this won’t be one of those situations where I get it after I post… tor onto . fin al site . com
If you have a touch device, please go to your settings and turn off touch screen to replicate my problem if you want to help.
Scroll down to the gray section. It will scrolljack (ugh) and then begin sliding.That all is fine and dandy. Now, if you click the circles, it should be able to take you to the individual slides. There are 5 slides. The initial state (which you can’t get to by the circles), slide 2/3/4/5 (representing the first/second/third/fourth circle). I’m using scrollMagic and I’ve been to their documentation, but in terms of scrolling to scenes, my scenes are a little more complicated than theirs. If you look at journeyNoTouch() function in main.js, you can see at the top how I’m attempting to scoll to the scene. It’s not working because the scenes are layered on top of each other. It works if you’re starting from the top and going to the bottom (because they are yet to be layered (but even that is a bit off because of it not quite lining up)), but if you’re at the end of the slider, it doesn’t work because all the offsets are the same.
As a very simple starting approach, When going top down I notice that the opacity of the lower slides is set to 0, whereas when attempting to go from the bottom up, the lower slides are set to 1.
/me asks his rubber duck debugger - “They’re not the same. Would it help if they were at the same opacity?”
Ultimately when going up to previous slides, you’re wanting the state of those slides to be the same as what they would be when scrolling down to them, right?
Is it viable for you to loop through the remaining lower slides setting their opacity back to 0?
From slide 2 when you click on the button for slide 3, you are scrolled down to slide 3 to view it, and everything is good.
From slide 4 when you click on the button for slide 3, you are supposed to be scrolled up to slide 3 to view it, which currently doesn’t occur.
Why does scrolling happen when going down, but not when going up? Is that the crux of your problem?
Yes, I highlighted this in my initial post. It’s because of the way the scrolljacking works.
Basically if you can imagine this, when you start at the top of the document, imagine below the viewport, all the slides are verticallly stacked on top of one another. As you scroll down, one comes into view and gets position:fixed to the viewport. The next slide will then come up and get position:fixed, etc etc. So when are you below all the slides, they are all top:0; and on top of another, instead of being stacked.
I think the scrollto scene, which the documentation page has an example of (although they are always stacked since they are static elements), bases its scrollto off the window offset, which , when stacked (as they are when you are at the bottom of the window), they are all the same.
When you give scrollTo a number instead of newpos, that results in the page correctly going up.
This implies that the newpos value is good when we are scrolled at the top, but bad once we’ve scrolled to the bottom.
When going down, ScrollMagic’s scrollTo method knows how to get the correct value. How does it figure out that value when you give it the identifier for slide two versus slide three?
If you can work that out, you can then save those values when the page first loads and then refer to them later on.
It looks like they just make use of the window.scrollTo method. I went to the uncompressed version in their github. Even their scrollTo is off by about 150px; story below…
I think I’m making a breakthrough though.
I’m not sure what this means, but can you all look in the console? You’ll see three values. One is the #fsHeader height, another is the .our-stories-container height, and the other is the offset for the .journey-container.
For some reason, a + b does not equal c. And it should. I notice when I tried manually doing .scrollTo (both scrollmagics version, and a version of my own), it would almost work, but it’d be off by about 150 pixels sometimes, which is what the difference in these values are. I think this is something big.
If we can work out why the difference is there, I can account for that in my equation and I think this might be solved.
It’s great to see that you’re making good progress there. I cannot help much more at this stage and other things (sleep, travel, obligations, etc) will keep me preoccupied for the next few days.
Someone else around here though should be able to lend a further hand with things.
Hmm, I’m still having issues with this. I just can’t seem to figure out where the extra values are coming from and how to predict it. I’m trying to scroll based on slide height (look at the journeyNoTouch(), but depending on screen width, if you click a circle, it’ll take you to a slightly different position. I can’t figure out how to account for it.