Leaderboard

Hi @Ikai, Thanks. Here two worthwhile articles: tutplus: how-to-intersection-observer Jonathan Harrell: controlling-element-visibility Kind regards Mikel

I've said it before and I am not ashamed to say it again. I am scared of StackOverflow... You can add a Polyfill to cover the rest of the browsers (erm... IE) that do not support it. It's pretty good from what I have worked with. There are several. Bellow are a couple of discussions I can remember from the top of my head:

Chrome did add a built in lazy load for images below the fold of the viewport months ago. I wonder if those new versions is causing a conflict or that buggy re-loading of images. Which would not surprise me based on Chromes track record with not being consistent about features and those features consistent behavior. Based on that lazy load feature in Chrome there have been reports that users with intermittent network connections, images may fail to load when scrolling down the page or trigger a reload. Hopefully they work it out. But you can always submit a bug report to Chrome Developers and see if they can fix your issue. They are pretty good (sometimes) on fixes their bugs. Happy Tweening

Ikai, look at Mikel's post - That's the answer to your struggle.

Hi, A slightly different approach ... https://codepen.io/mikeK/pen/xNrOyX Happy testing ... Mikel

Hello Ikai, Welcome to (the non-lurking side of) the forums! To me, it sounds like you should just look into the Intersection Observer API - with it you will be able to have each box fire a call to animate itself when it comes into view fairly easily.

I guess i'm a glutton for punishment and I couldn't help playing with this. I found that pins really threw a wrench in things as far as trying to setup triggers for panel scrolling so I separated that part into a separate wheel event. I'm sure there's a way to make it work all in scrollMagic but I"M NOT FIGURING IT OUT!? I did figure out what i thought was one kind of cool thing - using a flag variable and onComplete to make the wheel event/Tween self throttling. https://codepen.io/Visual-Q/pen/eaWeLv

In combination with css grid, it could be problematic. Test hard core ...

Hi @andystent, There's a lot going on in your pen .. and a lot of duplication of work which could be greatly simplified. That said ... consolidating everything (kind of as is) into single calls will make one button press control two sets of tweens. https://codepen.io/sgorneau/pen/mYwOdP?editors=0110 But, you should look at refactoring your code to get rid of unnecessary complexities.

@mikel Wow you are a true superhero! This is exactly what i was trying to go for. I'm going to make sure i understand every line of your code. Thank you so much!!!!

Unfortunately I haven't used IntersectionObserver before and I can't read ES6 worth a crap otherwise I'd try and jump in. MDN looks like it has a pretty good walkthrough for setting them up: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

You need to add the gsap scrollTo plugin https://cdnjs.cloudflare.com/ajax/libs/gsap/2.1.2/plugins/ScrollToPlugin.min.js and while it's not necessary in this case as you're calling gsap in callback function you might want to add scrollMagic gsap plugin if you ever want use setTween anywhere https://cdnjs.cloudflare.com/ajax/libs/ScrollMagic/2.0.6/plugins/animation.gsap.js Seems to work now. https://codepen.io/Visual-Q/pen/YbQqvN

Since you're dealing with two timelines here, you need to make some changes. When you play the forward timeline and then play the reverse timeline it works because that's their first play. When you click again to play nothing happens because they've already played. You can fix that by using play(0) or restart()which will play from the beginning of the timeline. Another problem two timelines creates is by playing the reverse timeline, you're not changing the reversed status of the forward timeline. My advice would be to use fromTo() tweens on both timelines and just use a forward/reverse toggle variable. This is where having one timeline to simply play/reverse makes things a bit easier. Having separate timelines targeting the same element can also cause a fight for control of the element if you click too quickly. I think this thread can help. Happy tweening.

Here it is https://codepen.io/jorgeduardo/pen/XwRXgB

Yup! Solves the problem. Thank you for your quick responses.

Hi @ikai, It has - I suspect - something to do with both. During the forward and back action, the observer reacts strange ... Hence my second example. But I'm not a pro! Kind regards Mikel

Aha! I see the problem. GSAP does a ton of work to manage conflicts and ensure that things run smoothly even if you interrupt things mid-tween. One of the things it does in the case of a className tween is to see if there's already one running on that element, and clear things properly (which likely involves editing/reverting inline styles). To work around some browser inconsistencies and ensure that things render properly, it records the element's cssText (all the inline styles) and then after it does its work of applying the new class and analyzing the differences in all the properties, it re-applies that cssText. In your case, that entails background-image too but you've actually got a URL that changes the image supplied randomly! You can get the exact same effect by removing TweenMax altogether and simply doing: //doesn't change anything, but the browser re-loads the background-image if you've got cache disabled: elem.style.cssText = elem.style.cssText; I'll add a line to CSSPlugin that only runs that code if the recorded value is different than the current one. Seems to resolve this edge case. You can preview the next version of GSAP (uncompressed) here with that change in place: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js Better?

Here another example (found at CodePen): https://codepen.io/mikeK/pen/jowwro

Hi @Ikai, The pen is modified ... If that is the expected behaviour fine. Kind regards Mikel

It seems a reasonably efficient implementation for scrollMagic as long as you're using only full height panels. It really hinges on scrollMagic performing reliably across devices and browsers, that you'll have to test.

While it doesn't fix it I think it should be new IntersectionObserver you had Obserber

Oh wow. So simples, so nice. I is *totally* jealous. Be ready to be ripped off without warning.

Also, for the record, I'd recommend avoiding className tweens because those require looking at literally every...single...CSS property to find anything that has changed between the old and new className, and then tweens each one. It's much better to just specify the properties you want to animate. If all you're doing is swapping classes, it's probably simpler to just use a CSS transition. Oh, and there is one case where an image's src must get updated internally, and that's for backgroundPosition because it has to measure the width/height of the native image so that it can accurately handle things like percentages. As far as I know, it's impossible to do otherwise. I found the original email notification about this thread and it contained a link to a valid codepen, so I peeked at that and it does indeed look like you've got a backgroundPosition in play there, and it's percentage-based. Perhaps that explains things.

Not quite sure what you're doing, but you can also animate the viewBox. Here are a couple of old pens that show the technique. https://codepen.io/PointC/pen/OMabPa https://codepen.io/PointC/pen/XbqBmM