Jump to content
Search Community

className tweens change units

iamjem test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

When doing a className based tween, the unit of properties is not respected. Here is an example:

http://jsfiddle.net/KxfUN/

 

I would expect the tween to see that the start value is a percentage for the top property, and the end value is a percentage, and adhere to that unit. However if you inspect the element during the tween, it uses pixels.

 

If I'm able to explicitly use percentages in other CSS tweens (ie TweenMax.to(element, duration, { css: { top: "50%" } }) ) then it should behave the same in className based tweens, no?

 

I think this is valuable in the rise of responsive websites where viewports are of varying sizes, and percentages allow developers to create "fluid animations" (using percents or other dynamic units) that work everywhere. If I resize a browser amidst a paused tween thats done these conversions, it's likely going to produce undesirable results.

 

 

Link to comment
Share on other sites

I see what you mean, and we'll look into this for a potential future release. We're working very hard on a few other features right now, and given the fact that the px tweens visually look the same (unless you resize the browser mid-tween, as you mentioned), it's somewhat of an edge case that we can't prioritize quite yet. It's not as easy to implement as one might think :)  Thanks for bringing this up, though.

  • Like 2
Link to comment
Share on other sites

I looked into this a bit further and the problem is actually how the browser reports the computed style data - it does so in pixels in this case, not percent. GSAP has to look at the beginning and ending values (after applying the class) and construct the tween accordingly, and since there could be all sorts of css rules applied to the target element, the only reliable way to get the "real" values is to ask the browser itself for those (using document.defaultView.getComputedStyle()). Since the browser reports the values in px instead of %, there's no way for GSAP to know that you actually want it to be in %. See what I mean? 

 

So to summarize, this isn't a GSAP issue - it's a browser issue and I'm not sure there's an elegant way around it. If you (or anyone) have ideas, I'm all ears. 

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...