[Tweening top: calc() value not working in Safari]

I didn't know about the invalidate() function - that looks perfect!

 

I understand. .. but if you choose to use calc(), then you are not making your code cross browser to reach a wide range of users. And then your limiting your animations to only those browsers that have partial support for calc().

 

IE11 is the only version of Internet Explorer for Windows 7, since MS Edge is only available on Windows 10.

 

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.

[Tweening top: calc() value not working in Safari]

Oh, and if window.innerHeight changes, you just create a new tween the overwrites the old one (or you could manually kill() it). It's pretty trivial to set up a "resize" listener to trigger that. 

 

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.

[Tweening top: calc() value not working in Safari]

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.

 

The following are known bugs and issues with CSS calc() cross browser.

• IE11 is reported to not support calc() correctly in generated content
• IE11 is reported to have trouble with calc() with nested expressions, e.g. width: calc((100% - 10px) / 3); (i.e. it rounds differently)
• Firefox does not support calc() inside the line-height, stroke-width, stroke-dashoffset, and stroke-dasharray properties. Bug report
• Safari & iOS Safari (both 6 and 7) does not support viewport units (vw, vh, etc) in calc().
• IE & Edge are reported to not support calc inside a 'flex'. (Not tested on older versions)
  This example does not work: flex: 1 1 calc(50% - 20px);
• IE10 and IE11 don't support using calc() inside a transform. Bug report
• IE 9 - 11 don't render box-shadow when calc() is used for any of the values
• IE11 does not support transitioning values set with calc()
• IE10 crashes when a div with a property using calc() has a child with same property with inherit.

 

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..

 

Regarding window.innerHeight .. There should be no bottleneck for getting the window height In JavaScript, since it is a very common thing, and is very straight forward.

 

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.

[Tweening top: calc() value not working in Safari]

Thanks for your input everyone! I appreciate all the thinking here!

 

I certainly wouldn't consider the lack of tweening "calc()" values in GSAP to be a "bug" because it strikes me as impossible to do. How could it animate between dynamically calculated values?

 

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.

 

 

Oh, and if window.innerHeight changes, you just create a new tween the overwrites the old one (or you could manually kill() it). It's pretty trivial to set up a "resize" listener to trigger that. 

 

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.

 

 

Just to add my two cents.

CSS calc() is still listed as experimental, so it's really not ready for prime time due to all the browser bugs and inconsistent calculations within each browser. It will probably be awhile before calc() can be used where it will calculate properly across modern browsers.

 

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.

[Tweening top: calc() value not working in Safari]

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/

[Tweening top: calc() value not working in Safari]

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): 

See the Pen WwWbjJ by ryangiglio (@ryangiglio) on CodePen

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: 

See the Pen MyRwYW by ryangiglio (@ryangiglio) on CodePen

It moves them relative to their own height, so -100 tweens them up by 1, -200 up by 2, etc.

[Tweening top: calc() value not working in Safari]

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?

[Tweening top: calc() value not working in Safari]

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?

[Tweening top: calc() value not working in Safari]

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!

[Tweening top: calc() value not working in Safari]

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!

See the Pen bpZjpe by ryangiglio (@ryangiglio) on CodePen