Leaderboard

In your 2nd each() loop you have this on line 67 TweenMax.fromTo('.fixedtitle', 0.3, {autoAlpha: 0.6}, {autoAlpha: 0.1, ease: Power4.easeNone}) That is targeting all h1 tags as they all have that .fixedtitle class so they will all animate at each trigger point. You need to target only the h1 in that iteration of the loop just like you did in the 1st each() loop. You can either assign it to a variable or drop it straight into the tween like this. TweenMax.fromTo($(this).find("h1"), 0.3, {autoAlpha: 0.6}, {autoAlpha: 0.1, ease: Power4.easeNone}) Happy tweening.

Hey Jack, thanks for your reply ! It makes sense then if it is a legacy thing. To be honest I feel like it doesn't really matter whether the wrapping is done outside or inside the target, as long as you don't have to worry about exceptions and inconsistencies. Do you think it still makes sense to have this feature since SplitText is now able to split apart nested elements?

First of all, thanks for the kind words, @Origine! Glad to hear you're enjoying the tools. And yes, that's actually something that was intended to be a convenience, particularly back before SplitText was capable of splitting apart nested elements. The logic was that if someone tried splitting something that only had one child element, it'd be smarter to split inside that child (since, again, it wasn't possible to split multiple children). But that's probably not very useful anymore now that SplitText has evolved further. If anyone disagrees, let me know. I updated the codepen-specific flavor of SplitText if you want to try that out.

I'm kind of confused by what you mean by "how do I run two different classnames at the same time". If the demo below is what you want, let me know if you need help understanding how it works

Hi @green_machine If I understand your question correctly, I think you can get the data you want by using getBoundingClientRect(). Something like this: Does that help or have I misunderstood the question? Happy tweening.

I can't really think of a great reason at this point, no. I'll remove that in the next version (unless someone else chimes in with a good reason to keep it). Let me know if you need that file right away and I can get you an advanced copy, but like you said, it really doesn't break anything so you should be fine. Happy tweening!

Thank you for the clarification here, really appreciate it. Indeed "disabling" 3D would hurt in the most of the case how Customers use our product, so will check if i can somehow reduce the parameters and needs on splits on demand, or optimize DOM Manipulation by preparing things in "CPU Free time". Thanks again and wish you a great day ! Greensock forever ! You are the best ! Cheers from the ThemePunch Team.

Yeah, browsers can all be pretty different performance-wise. The only thing I can think of that may be different in Safari when it comes to GSAP is that in order to work around some Safari bugs, GSAP sets a z-index on elements that are having transform-related animations applied. And for Safari 6 and earlier, it'll set WebkitBackfaceVisibility (again, to work around bugs). Other than that, perhaps some browsers handle the promotion of transformed elements to layers more efficiently than others. So you could try setting force3D:false to see if that helps anything (though it may actually hurt in some cases). Or set it to true and see what effect that has. I hope that helps!

durations aren't function-based like that. If you have a reference to the tween, you can use its duration() method to change the duration. However, if you have a timeline with 2 tweens tl.to("a", 1, {x:200}); tl.to("b", 1, {x:200}); the 2 tweens will naturally play in direct succession. If you change the duration of the first tween to be 2 seconds long (after the timeline is built), the second tween is NOT going to be moved to a startTime() of 2. If you want to dynamically change durations and end values for the properties you are tweening, your best bet is to re-construct the timelines, as mentioned earlier we recommend you just use a function to that heavy lifting for you.

I think you might be using an outdated version - that was one line in 2.0.0 that caused issues with some minifiers (like Uglify) that didn't understand ES6 destructuring, so we pushed 2.0.1 which fixed that. Maybe you've got something old cached? I'm pretty sure if you update to 2.0.1, the problem will go away.

Have you tried setting allowNativeTouchScrolling:false? That's a really old OS and I don't have a device with it currently. Seems to work great in more modern OS versions.

Sorry, not really sure what to tell you. I didn't see any animation in the demo and I'm not at all familiar with basicScroll.js so I don't what it's doing under the hood. I'd guess that the majority of high-end sites that have scroll-driven animation are using GreenSock with ScrollMagic. ScrollMagic hasn't been actively developed (or supported) for awhile but I'm confident it can handle what you need to do for this project and GSAP is highly optimized for performance.

Oh, all the H1 tags are still separate in the each() loop. The [0] is just to get to the actual H1 in the jQuery object. That was necessary for ScrollMagic to pin the actual H1 instead of trying to pin the jQuery object. If you were using a regular loop with a selector like document.querySelector(), that [0] would not be necessary as you'd have an actual DOM element. If you want to see the object that jQuery returns just use it as a selector and console.log() the variable to take a look under the hood. The only other thing I changed was adding the each() loop index to the indicator names so you can clearly see which one is which. Happy tweening.

Thanks for the demo. I couldn't figure out why the huge blockletters timeline was there so I removed it and simplified things quite a bit. The tricky part of this is that SplitText and TextPlugin can't really work in conjunction the way you have planned because SplitText literally sucks all the content out of a div and breaks it apart into new divs - replacing whatever was there before. The problem with your approach in simple terms is that you are using the variable chars to refer to radically different elements throughout the life of your timeline. When your timeline is first created, chars means one things... but as it plays you are attempting to change those values by using TextPlugin and SplitText. Trust me, its not the easiest thing wrap your head around. Again the basic idea is that SplitText radically modifies the DOM by creating new elements and replacing old ones. I'm assuming you want to have an end result like this: http://codepen.io/GreenSock/pen/eNoyYr?editors=001 (edit was originally wrong) The key here is that there is a function that generates a timeline based on the existence of some text in an Array. Since each animation is in essence breaking apart text in the same DOM node it is imperative that the second sequence isn't created until AFTER the first sequence is played. So the timeline-creating function creates timelines that check to see what the next timeline should be when they are done playing and then the next timeline gets created and played. You will notice this works pretty well, however there are some serious drawbacks, most importantly, you can't really control this sequence, especially you can not reverse it or restart it. If you want one timeline that you can play, pause, reverse, restart you will have to abandon the notion of replacing the text in a single DOM node for each sequence. It would be much better in my opinion to create new container divs for each sentence of text that you need to animate. I might be able to find or produce a demo that does that a little later today (or if someone else has one, cool).