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