Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

NickWoodward

Members
  • Posts

    99
  • Joined

  • Last visited

Recent Profile Visitors

417 profile views

NickWoodward's Achievements

  1. A hacky way of avoiding fighting the css of this table - which i don't really want to do rn - would be to make each stagger animate a distance * its index. So they all slide out from behind position 1. Might look nicer anyway. Going to give that a try
  2. Ah, thanks for your response - I completely lost track of this question Unfortunately the thead in my actual project is static, and changing the position to relative causes other issues. Good advice on setting the properties on all items though. I've thought about doing that in the past, but wasn't sure if it was a good idea. Thanks.
  3. Ah ok, perfect, thanks a lot for your help!
  4. Just the way my brain seems to approach these types of problems! But you're right, your way seems much more sensible. I still can't guarantee I'd approach it like that next time if confronted with the problem, but leaving the element on the page seems like the way to go, I just need to train my brain with repetition! The only thing is I do have to change more than just the colour of the element - So I guess I'd do that by inserting a div within the alert element, a bit like this: https://codepen.io/nwoodward/pen/jOYoMKo?editors=1111 Looking forward to watching your Learn with Jason vid btw (that's you right?) Spotted it a while back
  5. Hello! I'd like to animate in an 'alert' dom element every time a button is clicked (sucess or failure), and would like subsequent clicks and alerts to override the previous one. I've "solved" my problem, in a way that, depressingly, represents my coding in general - it feels convoluted and a bit hacky. I was hoping someone could take a look and tell me how I should actually approach the problem! Thanks Nick 'well I guess it works' Woodward 😊
  6. Hello! Quick question, and this could very well be me being crap with stacking contexts, but is gsap doing something unusual here? I would have thought that setting the tbody's overflow to hidden, and setting the z-indexes of the thead and rows would have prevented the content from animating over the top of the thead. But 🤷‍♂️ I look forward to someone pointing out that I'm being an idiot 😄
  7. I did consider that 😄 I guess it was more for readability than anything else. Well, that and establishing that it isn't really possible and I'm not just missing something!
  8. Yeah, that and a big thing for me is understanding that tl.to() etc set up, rather than start the animations. I think a mixture of immediateRender causing odd behaviour, and dom elements not being found because I misunderstood how a tl is created then run, led to me trying callbacks, rather than calling a function that returned a tween or tl.
  9. Got the codepen done just to check my understanding. The only thing I'm now a little unsure of is again related to the earlier problem I had (removing/re-adding a dom element and trying to select/animate it). In order to select the right element I have to create a new tween or tl and add it inside a callback (Line 36). But this doesn't add animations to the main timeline - this means nothing after it will wait for the tween to complete (like lines 39/40) Should I split the tl in two and add each section to a parent tl? Does that sould like it would work? https://codepen.io/nwoodward/pen/bGYZWRJ?editors=0011
  10. Yeah sure I'll update that one. But really I was just thinking outloud, trying to explain what the code means more theoretically. It's all now working as I expect
  11. Perfect timing, that cleared up one of the bugs I was having 😊 (*edit: in fact I think immediate rendering definitely contributed to some of my confusion) So I've now I tried 3 different approaches. 2 work, one outside of the timeline as a callback, another adding the animation to the tl with immediateRender: false , and another doesn't at all, for pretty obvious reasons I think // No point adding to tl adminView.renderAdminLoaders(); tl .add(adminView.animateAdminContentOut()) // Returns a tl, added to tl .add(adminView.animateAdminLoadersIn(), '>') // Returns a tween, added to tl try { // wait for async request here const data = await getData(); ////////////////////////// option a // Callback, not an animation, so not added to tl, but executed at the right point tl.add(() => { adminView.animateAdminLoadersOut(); // returns a simple fromTo tween // nothing returned }); //////////////////////// option b tl.add(adminView.animateAdminLoadersOut()); // adds a simple fromTo tween to the timeline //////////////////////// option c adminView.animateAdminLoadersOut(); // returns a simple tween which is executed immediately } Option a: executes at the right time in the tl as a simple callback. Not part of the timeline, any animation added after won't wait for it. Option b: adds the fromTo tween to the timeline. But without immediateRender: false, the loader appears at the beginning of its parent tl (ie right at the start) Option : executes as soon as it can, behaves weirdly because it races the other timeline I *think* I'm starting to get this 😂 *edit: is option a the equivalent of calling adminView.animateAdminLoadersOut() in the onComplete() of adminView.animateAdminLoadersIn()?
  12. Yeah I do remember reading your explanation of that in the other thread, and I think I've understood/got to that in a very round about way: I think what's made things more clear is when you said that the entire animation runs on the next tick. ah ok - so I don't need to worry about it rendering the loaders prior to the summaryContent animating out because the .fromTo() sets the autoAlpha (virtually) instantly. When I thought those lines of code were responsible for executing the animations (so to speak), I was worried that the autoAlpha:0 wouldn't take effect until after previous animations had run to completion. Obviously now I know that's not correct Thanks again - I will try my best to only now use this thread as a reference!
  13. Going to try and simplify this: // Using renderLoaders Line 1: Find summaryContent element in the DOM. Add the animation to the tl Line 2: Add the callback renderLoaders to the timeline. It's not executed yet. Line 3: Find '.loader' in the DOM. Add the animation to the tl. This will result in an error because the element isn't there yet. tl runs on next animation tick, summaryContent animates out, the loader renders instantly and doesn't animate (which is the behaviour I've seen) // Using renderLoaders() tl .to(summaryContent, {autoAlpha: 0}) .add(renderLoaders()) .fromTo('.loader', {autoAlpha: 0},{autoAlpha: 1}); Line 1: Find summaryContent element in the DOM. Add the animation to the tl Line 2: Execute renderLoaders() immediately(?). Nothing is added to the timeline(?) and the loader is technically added to the DOM here before the animation runs Line 3: Find '.loader' in the DOM. Add the animation to the tl. This will work because the element is there already. tl runs on next animation tick, summaryContent animates out, the loader is already in the DOM prior to the tlrunning, so animates in at the right time. Hope that's right! 😂
  14. Haha, I picked up my copy of YDKJS which explains the compiler vs runtime to see if I could work out if it was related to this, and almost instantly put it down again 😄 Sure, but in my (probably incorrect) mind it feels like the .add() and the .to() are executed within the animate() function, so it doesn't feel (thankfully) like it's a compiler/parsing thing? How about this as an idea (and this is probably what you initially meant and I just misunderstood): The first time JS hits this code: tl .to(summaryContent, {autoAlpha: 0}) // target not found .add(renderLoaders) // fine // .add(renderLoaders()) .fromTo('.loader', {autoAlpha: 0},{autoAlpha: 1}); the .to() runs, selects the relevant dom element and adds the animation, the.add() adds the callback (which hasn't run yet but is put in the correct position in the timeline), and the .fromTo() does the same as the .to(), selecting the dom element and adding the animation. The '.loader' element isn't there yet. The timeline *then* executes itself after the entire timeline is created. Somehow? 🤔 The more I think about it the more I think this seems to make sense to me? Like I said, hopefully this is what you meant and I just misunderstood, because I really don't want it to be about compile vs runtime either! 😄 *Fake edit (because I didn't understand on the first read through) Ah, ok then. So tl.to() tl.add() etc are just like init functions, and aren't executing any of the animations. Got it. That makes sense (I think) My only problem with this (still) is that I now don't understand how .add(renderLoaders()) fits in (vs the callback). If tl.to()/tl.add() initialise the timeline, and the timeline plays on the next animation tick, doesn't that mean that renderLoaders() isn't added to the timeline at all, and is instead run during the initialisation for the timeline, before it even starts playing? Thanks again!
  15. Yup, it's definitely this line that I'm unsure of, especially the last part, about it being evaluated as soon as I write it. Is this a distinction between what happens at compile time vs run time? So the reference to'.loader' is being looked up prior to the animate function even being run? Or is this my confusion about when the timeline is constructed vs when it actually starts playing (and when the callback is run)? Sorry if I'm being thick, but I still haven't got my head around it.
×