Raynor

Hi! I wonder why css: {} autowrapping does not work for updateTo function. It seems a little confusing that i can use a simple shorthand syntax within tween properties, but have to print wrapped-in property like {css:{property:value}} inside updateTo function. And the other question: it seems like adding tweens to the timeline with shorthand syntax like this: timeline.to(target, 0, {property: value}); generates TweenLite tweens, that don't have updateTo method. Can I somehow create TweenMax tweens with this syntax at all or do I always have to use something like timeline.add(new TweenMax(target, 0, {property: value})); for this purpose?

I tried, but in this case it doesn't even work properly from the start. With font-size 16px, according to FireBug compiled style height for menu block is 51px. If I set height to "0%", it goes tweening height from 0% to 11.6% of parent container, which is approximately 89px . I'm not sure why this happens, but suspect it's because menu block itself is one of the elements in the parent flex-container, and somehow it impedes GSAP from determining initial height correctly. If needed I can create more detailed Codepen where you could be able to observe all this side-effects. But actually I found the solution to this problem: it was as easy as invalidate() timeline onReverseComplete. All ingenious is simple

Hi Rodrigo! Thanks for participating. I said above, that design is made so that menu (red element) size depends on the font-size, and font-size itself is responsive. It changes when you zoom or resize browser window and therefore target element height changes too, which causes this problem with animation. I just haven't included font-scaling script for simplicity, maybe I should have done that. The script is not based on media-queries; font-size (and element height) are changed smoothly, so literally any resize event produces a little discrepancy (for now, you cannot see that on codepen, but if you want, I will add the script to show you). But the problem is the same like the one you get with the steps I described above. Besides that, I try not to use media queries every other time when I can avoid it. In this case JQuery slider() method which I have used previously worked fine without them, so I hope it is achievanble with GSAP too. Single tween certainly works for the reasons you described, but I need timeline (there's some more animations that must be going on in sequence, such as setting overflow and visibility properties)

And here's the above-mentioned method to connect extarnal css stylesheet to embedded as <object> svg file. I made it work at last) You have to place this in the head of your svg file, just above the opening <svg> tag: <?xml-stylesheet href="../css/svg-style.css" type="text/css"?> <svg... Pay attention to URL path, if's usually better to give the full path starting from root folder. Slightly other way of doing the same: <svg> <defs> <link href="../css/svg-style.css" type="text/css" rel="stylesheet" xmlns="http://www.w3.org/1999/xhtml"/> </defs> ...

Well, it turned to be a challenge to properly reproduce this problem on codepen http://codepen.io/anon/pen/emWgZX I have a rather complicated situation where element's height is not set directly in CSS, but depends on content (text font-size, that is also adaptive). You can set font-size in the .box class and menu height will change automatically. Moreover, some flexbox magic is involved,and I kept it there just to give you easy way to reproduce the problem. So, to see what I mean: 1. adjust your window size so that 'flex-wrap' comes into action and you see blue boxes above each other. 2. Press 'click here to slide' to play the animation. 3. resize your window in a way when blue boxes are horizontally aligned and red element height is twice smaller. 4. Play animation again. You'll see that it starts from the place where the red element ended last time (before resize). One more thing: it seems that problem exists only for 'timeline' setup. If you omit timeline and put the tween directly inside 'on click' event, everything works fine without timeline.

Thanks Jonathan! xPercent and yPercent are really cool and thay do help in some situations, but they are for translations only. And what is often needed (in my case also) is to change property (height) of the element, not just shove it somewhere off the screen (well, it might pass as a workaround, but its not the way i want it and this solution is not universal). OK, I think codepen is needed here

There's the similar question that I wanted to ask, I think it will be OK to ask it here. I' trying to make GSAP animations work properly with responsive design. Let's say I have a responsive DOM element with height measured in vh or % rather then pixels. Then I tween its height with GSAP. The problem is, if I understand it right, initial CSS values get recorded only once when the tween is created. So, if I zoom page (and element's height is scaled proportionally by browser) and then restart animation again, GSAP will still tween to initial height than was recorded when page was unzoomed. I could try to use 'on resize' event to re-create the tween each time the window is resized, but it seems to be cumbersome and inefficient (resize events come very often and in fact i only need to re-record CSS properties once when resizing is over). Is there more elegent solution, maybe some method to renew initial values each time the tween starts? JQuery slide() doesn't have this problem but i don't know exactly how the things are put together inside it to reproduce its behaviour.

Yes, local server solves the problem! Thanks!

Diaco.AW, nice approach, I tried it with my project. It works with Firefox and Internet Explorer, but Chrome seems to have some kind of security problem with accessing embedded svg files. var doc = this.getSVGDocument(); //returns null Also, they say using .contentDocument is more advisable instead of .getSVGDocument(), which is deprecated, but this doesn't help with Chrome. http://stackoverflow.com/questions/22529398/getsvgdocument-returns-null-in-firefox-and-chrome http://stackoverflow.com/questions/337293/how-to-check-if-an-embedded-svg-document-is-loaded-in-an-html-page

As far as I'm aware, the best way to embed external svg file in html at the moment is using <object> tag. The syntax is like following: <object type="image/svg+xml" data="images/mySVG.svg"><!--fallback--></object> "Fallback" option here allows you to specify alternative image in standard jpeg format just in case user's browser doesn't support svg. So, you can take your svg code, place it in external svg file and connect it like that, but the downside will be inability to apply CSS stylesheets or use external JS scripts, everything should be contained within this svg file. To be honest, lately I read somewhere about possiibility to connect external CSS stylesheets to <object> svg, but haven't managed it to work (yet). For this reason I stuck with inline svg for now.

Thanks Carl, you considerations are very helpful and for the most part they match with what I've been thinking. My usual approach to things (not only in web-development) is to build everything as flexible as possible from beginning, so in the case I want to change or elaborate something later (which often happens) I wouldn't have to do everything from scratch. From this point of view, certainly, GSAP wins the competition. Can you propose some kind of valid test to compare JQuery/CSS vs GSAP performance in custom project? Because i see that I haven't accounted for everything when I tried to do it with console.time

I see your point. The last option that you mentioned is exactly what I was talking about, it just didn't get through to me why you consider this behaviour undesirable. I think the vast majority of people prefer transform-origin in the center (maybe you can do some kind of poll on this matter?), and, if they are already using GSAP, it would be more comfortable to set any other transform-origin they want directly in the tween options, rather then in CSS. I am eager to know what other users think on this matter.

1. Well, yes, somehow I thought that "it creates a zero-duration tween but it automatically sets immediateRender:false" meant that set() method differs from .to() in the aspect that (for zero-duration) .set has 'immediateRender:false' by default and .to has 'immediateRender:true'. In that case, setting immediateRender:false explicitly would make no difference in comparison with default .set(). Should have read more carefully. 4.Oh yes, now it's getting clearer) Sorry if i'm asking obvious things, I'm still a newbie but trying to learn. So, there's no sense to compare this way. For simple class switching JQ will do the job, but what about short animations? For example, I can use CSS class + JQuery toggleClass + CSS3 transition to morph some property, or I can use CSS class + GSAP className to toggle it with morphing. Is JQuery approach better again? I'm concerned because: 1) I don't like when animation parameters are spread across .css and .js files (JQuery in js file, transition parameters somewhere in .css) - using one function to rule them all is more comfortable IMHO; 2) For svg and IE, only GSAP method will work, and I'd like to go with one tool for DOM and SVG for consistency. From this point of view GSAP is preferrable, but the question is how slow it will be comparing to JQuery/CSS method in this case. For animations that do not involve classes switching GSAP wins all the way, if I get it right.

Thanks for your help! Yeah, I know that Internet Explorer does not support 3D transforms for svg, nor does it support svg CSS3 animation, but in this sense GSAP stands out with its own animation engine and ability to morph CSS classes, which actually works with svg in IE! And that allows to make svg animations that are crossbrowser-compatible (for the most part). As for 3D, I think i can live knowing that if won't work in IE, while basic things like Y-rotation works nicely in FF and Chrome (anyway, it's mainly used just for decoration). So, I'd like to have it keep working in FF (I have some effects in my current project) - no good when it works in CSS3 and doesn't in GSAP, agreed?) I just was surprised that it worked in 1.14 and didn't in 1.15, which made me think that something was accidently broken in new release. Next, as for transform-origin. If I understood your properly, the problem here is that what works for DOM, doesn't work for SVG. With SVG, you cannot rely on what browser is telling you because (I suppose) it will always set transform-origin to the upper left corner of the element, and that's not what we want. I think what is needed is different method to calculate transform-origin for svg. Snap.svg for example has transform() method that always sets tr.origin correctly in the center of the element by default. I think maybe GSAP could use some kind of Snap getBBox() function to automatically determine svg element coordinates on svg canvas and apply them as default transform-origin value. For example, we can get bounding box for the element with .getBoundingClientRect() and take coordinates from there. I guess in the vast majority of cases that will fit with what user wants to achieve. If, for some reason, user decides to rotate around left top, he can just enter either {transform-origin: left top} or {transform-origin: 0 0} and it will work (like it actually works now). If transform-origin is set manually in CSS stylesheet, GSAP should override it. Just my thoughts, maybe I'm missing something

Thanks Jack! So, correct me now if I am wrong: 1. set() method by default has immediateRender:true when used immediately upon creation and immediateRender:false when inserted in the timeline? I'm referring to this phrase: Because in my example it behaves differently in default case and when {immediateRender:false} is set. 2. So, in fact, total execution time is the same in any case, the difference is just that with {immediateRender:false} its 'render' part just doesn't get measured, because it happens on the next tick; 4. Jquery toggleClass method is really several times faster (it shows about 1 ms execution time, when measured in a function like this) function toggleJQ(trigger, target, className) { $(trigger).on('click', function() { console.time('JQ'); $(target).toggleClass(className); console.timeEnd('JQ'); }); }; but GSAP has extended functionality. So, for simple tasks (instant class switching, for example) JQuery toggleClass is preferable compared with zero-duration tweens, but for more complex things with animation involved GSAP is the way to go? I'm just trying to decide which tool to use in which situation. Or am I incorrect, maybe JQuery does render on the next tick as well and I'm comparing apples to oranges?

I'm sorry to resurrect this thread, but haven't anyone noticed dramatic loss of performance when using zero-duration tweens? For example, I use zero-duration tween to set some attributes, and measure function execution time with Firebug console.time method. It shows me 12-18ms execution time. When I do the test with "immediateRender:false" added, it shows 0.3-1.2 ms. The same happen when I use .set method instead of .to - exactly the same behaviour, slow by default and fast with "immediateRender:false", though, as Jack said above, .set is suggested to have "immediateRender:false" by default. Here's a Codepen you can test in FF with Firebug console http://codepen.io/anon/pen/gbWYJg

Hi there guys! I am a newbie to GSAP - discovered it while searching for universal cross-browser tool to make efficient animations for the web-sites. In short, it's great) I'm planning to use svg a lot, so it's crucial for me how it is handled in GSAP. I delved deeper and did some experimentation, and as a result I came up with what seems to be a bug: - 3D transform (rotationY, for example) does not work in Firefox, though, in contrast to IE, it is supported in FF. It took some time until I figured out that with earlier versions of GSAP (back from 1.14.0) everything's working fine. No problems in Chrome as well. - The next thing that annoys me a little is the necessity to use {transform-origin: "50% 50%"} each time to make svg element rotate around its center; as opposed to what is written in "getting started" guide, it seems that this value is not default for svg elements: their transformation is done around left top corner if {transform-origin: "50% 50%"} is not defined explicitly. See both cases on Codepen here http://codepen.io/anon/pen/jEmNyw. Thanks!

Hi! Try version 1.14.0 of GSAP instead of latest 1.15.0. I noticed the similar problem with svg 3D-transform in Firefox lately and found that with earlier versions of GSAP everything is working fine. I'm prepairing the bug report at the moment.