Jump to content
GreenSock

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

ryangiglio

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

3 Newbie

About ryangiglio

  • Rank
    Member
  1. I didn't know about the invalidate() function - that looks perfect! As long as you're sticking to the basics it was originally intended for (my example from before - stretching a content area next to a width-width sidebar), calc() is actually supported all the way back to IE9. Most of the bugs in that list are weird edge cases that wouldn't normally come up in styling a normal website. I've used it on a bunch of sites in the last few years and have never run into an issue. In this specific case I'm working on an internal tool and I know everyone will be using the most recent versi
  2. This ended up being the best solution. There's not too much overhead removing and recreating the tween. Simple is best! Huge thanks everyone for taking so much time to discuss and explore this issue! I'm relatively new to GSAP and this is a pretty fantastic community.
  3. The reason my layout is so finnicky is because I'm trying to make this work (partly for academic reasons) without hard-coding their positions based on nth-child. Since the links are relative positioned inside a fixed position container they can stack naturally while still being stuck to the bottom of the window. If the links were fixed position I would need to manually position each one, which I'd like to avoid. While that's a pretty long list of bugs, most of them are specific to IE and none of them are really debilitating when you're using its most basic functionality which is why t
  4. Thanks for your input everyone! I appreciate all the thinking here! I definitely don't consider it a bug in GSAP, but I do think it's a bug in Safari based on the fact that it works as expected in Chrome and Firefox. I understand the logical impossibility there so I imagine it's doing something tricky under the hood to return an actual pixel value to anything trying to use/manipulate it and it's just representing it to the dev/user as a calculated value. This is probably what I need to do - I was thinking it would be a little processor-heavy but I can't imagine resizing th
  5. Thanks for chiming in! That was what I tried originally, before resorting to calc(). As far as I understand, GSAP caches the value you passed when you originally setup the Tween. After that it's just animating in stages between its current state and the original value you gave it, regardless of whether or not that value has changed since you set it up. Here's an explanation as to why that's the case: http://greensock.com/forums/topic/10332-update-tween-value-while-its-tweening/
  6. I fear this won't be possible as-is without using vh. I may need to rethink the way the whole layout works. Because they're relatively positioned inside a fixed position container, any kind of percentage-based y value on the links themselves is going to be based on their own height which isn't helpful. To stick the links a fixed distance from the top I need to know the height of the window dynamically whenever it's resized which only seems to be possible with the vh unit Here's a few iterations that I've tried: Eliminating calc entirely and replacing top with y (your original comment)
  7. I'm having trouble figuring out how to use yPercent to implement this specific calculation, because it's still partly a fixed-pixel value (which is why calc() was my instinct - it lets you mix those kinds of things). Simplifying the variables for the sake of discussion, I'm trying to tween towards y = -window height + 350px. Is this possible with yPercent?
  8. So actually I was a little hasty - problem not totally solved yet... Now I remember the reason I used calc in the first place - this needs to be vertically responsive. So if the user resizes the height of the browser window after they've loaded the page, the target value of the tween needs to update to reflect that. With calc() that happens automatically, but it doesn't when the value is calculated at page load. Is there a way to update the target value of the tween after it's been created?
  9. Thanks for your really thorough answer! I'm relatively new to GSAP after having done most of my animation/transitions using pure CSS for a long time so I'm not used to thinking outside of the confines of CSS. You're right, it doesn't make sense to use calc() when I can just...calculate the exact pixel value with Javascript. That was a fairly trivial change and it totally worked!
  10. I'm creating a relatively complex nav layout for a single-page scrolling site using GSAP and ScrollMagic. The "upcoming" page in the navigation tweens upward as you scroll down until it hits the top of the nav, and then a page transition is triggered (which is unrelated to this issue). I've included a stripped-down Codepen with only the Nav - please view it in Full View using Chrome or Firefox to see the effect working properly. The value it's tweening to achieve that effect is relatively complicated - it's top: calc(-100vh + [nav container height] + [2x nav bottom property]) which has the
×