Ginger Soul

Thanks @OSUblake! Looks like CSS is the way to go on this.

Hey, I’m sure this has been asked before, but I can’t seem to locate a thread about it: I’ve been animating stuff by using a set() tween (to set initial styles, e.g. opacity 0), then executing a to() tween to animate a target (e.g. to a style of opacity 1) when it’s time to do so, based on an event, like scrolling the page. Common 'entry animation' stuff. To cut down on the 'double tweening,' I'd like to start using from() tweens for animations that return a target to its 'default state,' but I'd like to avoid a FOUC before the from() call has a chance to do its thing and style the element. I know I could use CSS to hide the target initially by styling it to match the from()'s properties, but I'd like to instead explore a 'body curtain' of sorts to keep the entire layout from showing until all my from()'s preparations have completed. This would keep the entire animation lifecycle/definition in the JS and allow animations to be added/removed from elements without having to touch markup/CSS - knowing that I could count on the body not showing until everyone was in the right position, even above the fold stuff. I should mention: I have an animation product built with GSAP (happy BG commercial license holder here) and would like users to be able to just 'attach an animation to something without having to style the target as well.' And I can't stand FOUC and would be willing to make visitors wait a few milliseconds to prepare the scene properly I assume the from() 'does its thing' as soon as possible, but I'm not sure when that is (nor when/if it tells us that it's done 'setting up' with a callback). I’m willing to accept the 'just style it with CSS' answer if it's not possible to listen for from()'s doings, but I thought I'd ask here first. Thanks! Dave Bloom

Big thanks to @ZachSaucier on this one. Helped me with a nice reveal animation today. DB

@OSUblake man, I've heard of the shadow dom but this is the first time I've seen it in action. Behind the times, I guess. Where's the script coming from? Is this more performant? DB

Agreed

Few thoughts: Web design is a service industry. You're supposed to do what the client wants (or what will delight them), even if it's semantically 'messy' sometimes. If there's a wayward span in your markup, that's what comments are for. There's thousands of lines of code at work getting a website to render stuff; one little UI hack isn't going to tip the scales. Explain what you're doing for the next dev. Being a purist about things like markup and performance usually has me going back to this article. UX wins in my mind.

As someone who gets paid to implement solutions like this, I'm often glad that a workaround is required. @Cassie just taught me something that I can use to impress my customers: giving the impression of a smoothly animated box shadow that I can throw behind buttons/cards to add depth to my designs without introducing jank. Given the fact that it's not straightforward, it's going to be that much harder for other developers (competitors, peers, etc) to implement, which adds value to my offerings. If web design was straightforward, easy, and simple, I'd be out of a job. So while I'm optimistic that browser performance and CSS specs will improve over time, and that this 'hack' may be unnecessary in a couple years, it puts me on the cutting edge and I'm going to run with it Dave

Props to @ZachSaucier for knocking three issues out in the same thread DB

On it! Thanks for listening

Right after I posted this, I thought I should clarify something. It'd be great to see a few examples from the GSAP team (CodePen collection anyone?) that cover best practices around 'toggling' or 'two-part, back and forth' animations, whether that's a simple dropdown menu (that either reverses itself with a reverse() call or uses a completely different tween/timeline for the 'reversal'), or a modal/dialog that flies in with one timeline (say, flying in from the top of the viewport) and vanishes (say, by scaling to 0.8 and autoAlpha:0, poof!) with another timeline. Or a snazzy mouseover/mouseout hover timeline on a card. Two-parters. In, and out. I see a lot of these scattered, 'how do I change props on reverse' threads, and I'll say this: I completely understand the logic of why you need to split that logic into two timelines. I've seen @GreenSock explain it a few times. I think the main concern from these submitters is that a 'power4.out' curve looks awesome coming in, but 'takes a while' to leave when the exit animation is triggered with a reverse() call. A reverse timescale speed-up is kind of a band-aid in this situation - the animation just looks better if you can also 'power4.out' the exit animation too. So, some best practices around 'Timeline Toggles' would be awesome to see as a reference. DB

I'm curious about this pen that @ZachSaucier created above. I'm trying to do something similar, but with timelines instead of tweens. My problem is, both 'back and forth' timelines play once, but when I try to play the 'forwards' timeline after having reversed it, its timeline progress is at 1 and it doesn't 'play again.' I'm trying to avoid simply 'reversing' the timeline animation. For things like dropdowns, it's nice to have the ease-out animation going both ways, as was echoed in the threads above. Can you show an example of this 'toggling' behavior with two timelines (ideally with multiple steps) instead of two tweens? Or should I set up the pen Thx! DB

Perfect, thanks - the answer is to add the CSS to set things up. Appreciate the speedy response!

Hey, wasn't able to find this in the docs. Let's say you want to animate something that's above the fold from zero opacity when the page loads (without using CSS to set the element's initial opacity to zero), but you don't want this scenario with the 'from' tween: 1. You see the element briefly (a 'flash of un-set content,' if you will), 2. the 'from' tween gets evaluated and 'sets' the opacity to zero, 3. the tween executes and animates the element 'back' to 1. I'd like to 'hide the entire layout' with a body opacity=0 while a series of 'from' tweens are setting up their values, but I'm not sure when to, uh, lift that curtain (aka transition the body opacity to 1) and allow the tweens to do their animating. Hope this makes sense. Thanks for any insights DB

Man, I just spent 90 minutes Googling and I'm so glad this thread existed Never shut down the messageboard, it's so vital to finding solutions to these types of conflicts! DB

Thanks, Zach. I'll put something together for you. Sorry for leaving that out, this was so...speculative that it seemed like I should ask first. DB

Gonna guess this is a no. I'll try to re-jigger the architecture on my end to place the timelines inside the proper .matchMedia functions. DB

Hey folks, Long time since my last post, but I've been working with GSAP again and I'm loving the Scrolltrigger. I'm curious if there is any way to get matchMedia functionality inside a timeline, or if there are other ways to reference it besides wrapping all your timelines with the matchMedia function. Can you 'ask' the matchmedia function whether it matches, on a timeline-by-timeline basis? I'm imagining something like this (pardon me if this looks ridiculous, I'm working on populating a timelines object from data-attributes using a loop, and wrapping all the 'eaches' in the 'kosher' matchMedia way is proving difficult). tl = gsap.timeline({ scrollTrigger: { matchMedia: '(min-width:800px)', trigger: '.element', start: 'top bottom', end: 'bottom top', scrub: true } }); // end timeline Thanks, DB

@OSUblake Great to hear from you, was hoping you'd chime in Happy to create a pen for this - it pertains to the functionality of an animation plugin I've been working on for a while. Think you'd dig it. Meanwhile, I'd love to catch up - I think we're still Skype contacts, hit me up! DB

Hey Greensockers, Got a question that I think has a pretty simple answer. I'm using a Timeline to animate three horizontally-aligned targets that share a common class (myclass), e.g. var tl = new TimelineLite(); tl.from('.myclass', 0.5, {left:100, opacity:0}); This works fine on desktop, when these elements are horizontally aligned and all enter a user's viewport simultaneously. On mobile, the elements stack, so when the Timeline fires, you only see the first element animate and 'miss' the other two animations as the target elements are below (outside of) the viewport. Here's my question: Is there a way to pause the Timeline after each 'loop' if its target isn't in the mobile viewport (aka run a function after each loop to check this), and resume the Timeline if that element enters the mobile viewport? I'd be combining this with jQuery Waypoints to watch for 'entering the viewport' events, I'm just curious if/how you can run functions during a multi-target timeline that has one 'step.' Thanks! Dave Bloom

Ah, that's helpful. I guess my jitter just came from a lack of memory I have an animation helper plugin that's in alpha, and I may now change my scale fx to translateZ. Thanks for clarifying.

Is this jitter going down on Apple's new design? http://www.apple.com/ The scale on the carousel titles? Just wondering if this is affecting the 'big boys...'

Thanks for fighting for us front-enders, Team Greensock I wonder what they 'fixed' to introduce this issue...perhaps there's another way to solve that problem that doesn't compromise our animation performance.

Now I'm seeing the jitter on scaling - can we do what we did last time and inform them that the competition seems to have a better handle on things? That seemed to light the right fire....

Any idea why will-change is to be used so sparingly? They used to say that about fats on the food pyramid, but I tried eating 6 baguettes a day and didn't lose my love handles. Is it bad for a single instance of animation performance, does it affect load times, or repaints..? DB

Best email I've gotten all day. Thanks everyone! DB