ryangiglio
ryangiglio's Achievements
3
Reputation
-
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 versions of Chrome/Firefox/Safari so that's not a concern.
-
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.
- 20 replies
-
- 1
-
-
- scrollmagic
- calc
- (and 4 more)
-
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 they haven't scared me off. I've used it pretty liberally in layouts and haven't run into an issue.. The bottleneck I was referring to was destroying/recreating the Tween every time the window was vertically resized - there's a lot more processing involved. I'm going to give that a shot regardless and see how it feels - I wouldn't want the position of the thing to be too jumpy during/after a resize.
-
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 the height of the browser to be so common a thing as for that to be a significant bottleneck. While I do realize it's considered experimental, I've used the basic functionality like width: calc(100% - 200px) to stretch the body of a site next to a fixed-sized sidebar and found it to be pretty reliable and well-supported. I'm definitely stretching it beyond its limits here.
- 20 replies
-
- 1
-
-
- scrollmagic
- calc
- (and 4 more)
-
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/
-
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): http://codepen.io/ryangiglio/full/WwWbjJ/ This works perfectly on page load - but if you vertically resize the window the spacing gets thrown off until you refresh Quick sample of what yPercent does: http://codepen.io/ryangiglio/full/MyRwYW/ It moves them relative to their own height, so -100 tweens them up by 1, -200 up by 2, etc.
-
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?
-
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?
-
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!
- 20 replies
-
- 1
-
-
- scrollmagic
- calc
- (and 4 more)
-
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 effect of moving each item up but maintaining the same spacing once they're stacked at the top. I know there's an outstanding issue with tweening calc() values that's been on GitHub for a while - you can't tween them unless you first use TweenMax.set to establish the pre-tween calc value. Using that workaround got it to work in Chrome and Firefox, but it's still not working in Safari. Instead Safari waits until the end of the ScrollMagic duration and then simply jumps to the end value. I'm not sure what to do about this issue - I've tested it in Safari and tweening a non-calc value works fine, but I need a calc in order to achieve the effect I want. Any help would be appreciated!