Leaderboard

@GreenSock thank you, now it's perfectly clear! SVG nuances are so confusing, really appreciate your support!

The SVG spec doesn't support 3D transforms - that's why rotateY doesn't work for you. And as I said in your other thread, GSAP uses the transform attribute rather than CSS transforms in order to deliver cross-browser consistency (work around various bugs and inconsistencies). You'll notice that the percent-based transform-origin values DO work as expected even though if you look at DevTools they're technically set to 0px. That's on purpose actually. We did a bunch of work to normalize things across browsers by adjusting all the other values in the matrix() accordingly. So it looks/works exactly the same, but the transform-origin's components are zero for SVG elements in order to make things work great across all browsers. Here's a fork showing that they work as expected: See https://css-tricks.com/svg-animation-on-css-transforms/ Does that clear things up?

The SVG spec does not officially support 3D but you can get the behavior you want using CSSPlugin.useSVGTransformAttr = false; however this is not recommend as explained here:

more details here: https://greensock.com/svg-tips

Hi therddlr, I think you may be misunderstanding what x:"40%" is supposed to do. To be clear it will translate the target a distance based on 40% of its own width, not to a position equal to 40% of its parent's width. I forked your original demo and used to() tweens instead of set() so that you can see what is happening

Hi @therddlr, Please take a look at this info: SVG-Tips

Hi Therddlr, Glad you are eager to learn.SVG definitely has its quirks, but as Jack mentioned, GSAP does a lot to normalize behavior. I'm sure you will do fine with GSAP. If you want to make your head spin a bit, read through the SVG Gotchas thread. Some great info in here:

Thanks Jack for getting this clear for me

Yes, that's to get around browser bugs (if I remember correctly, Safari had various glitches related to non-zero z values in transform-origin). We did a bunch of work to normalize things across browsers by making transform-origin's z component 0 and then adjusting all the other values in the matrix3d() accordingly. So it looks/works exactly the same, but the transform-origin's z component is always zero in order to make things work great across all browsers.

Have a look at this article about using the clip and clip-path properties in CSS. In short, css clip is deprecates, but will work in just about any browser including IE. Clip-path is the newer way of accomplishing the same thing, but with some newer bells and whistles. https://css-tricks.com/clipping-masking-css/ The tricky part with this technique is figuring out the correct values for top, right, bottom left because it's a lot of trial and error especially on non-rectangular objects. You can use the browser's inspector to manually change these values on the fly, but you'll want to disable any external or inline JavaScript code. I've found it best to use a TweenMax.to tween to change these values. You could end up with your object flashing on and off briefly when the web page is first loaded if you use a TweenMax.from tween. In your scenario: 1. Use clip: rect(0px, 0px, 0px, 0px) in CSS to make your object "invisible" on page load 2. Use a TweenMax.to tween to change those properties I also recently posted a thread about using the css clip to do exactly what you want; reveal and hide objects.

Hi @therddlr, The 100px are relative to the viewBox. A SVG only with viewBox and without width and height attributes makes it fully responsive in modern browsers. Therefore, the 100px are converted to the real size of the SVG of the viewport. More about this aspect for example here. Kind regards Mikel

Hi @therddlr, Is this your middle of the block?

Hi @therddlr Would it work that way for you? Happy tweening ... Mikel

Hi @soupking, a quick search in the GreenSock Forum and you will find almost everything. Here from our Mask expert @PointC: Happy searching ... Mikel

Just to chime in here Dima-L and vanillabass. As Jack said the SVG spec does not support 3D. In your codepen you are applying transformPerspective. Perspective and transformPerspective requires z-axis to work. But again SVG does not support 3D transforms, even though like Jack said Safari / Chrome webkit allows it in some instances, which goes against the spec. Safari and Chrome will sometimes allow non-spec behavior for developers, and then remove that illegal behavior to align itself with the spec. WebKit based like Chrome and Safari browsers are known to just add features for developers. But are not meant for production, for example on Windows 7 64-bit your example above isn't working for 3D on SVG elements. Since Firefox is good at respecting the spec. But in order to maintain cross browser consistency. It is better to not even attempt 3D on SVG elements, since doing so will give you problems like you are experiencing now for the reasons Jack mentioned above.

The official SVG spec doesn't actually support 3D transforms at all, so I wouldn't recommend applying them. Some browsers have partial support, but I really wouldn't count on it. This isn't a GSAP limitation - it's simply a browser/spec issue. Safari had some bugs (again, the browser, not GSAP) related to when the transforms were applied via CSS instead of the transform attribute. So we switched to setting transforms via the attribute by default which is the most consistent way to do it anyway across browsers. The transform attribute definitely doesn't support any 3D stuff. Technically, you can get back to the old behavior by setting the undocumented CSSPlugin.useSVGTransformAttr = false; (that's a one-time setting). That'll allow them to be pushed into the CSS style instead of the transform attribute, but again, the tradeoff is that Safari has some rendering quirks with that in certain rather uncommon scenarios. And of course even if you get the 3D stuff working in Safari and Chrome, IE and Opera certainly won't honor those. So my recommendation would be to avoid doing 3D in SVG since the spec doesn't really support it anyway. I wish I had better news for you.

No worries. And the tick events are after the tweens are updated, although it is possible to add a listener that would get triggered before the updates (set the priority to a number higher than 0).

Sure, let me explain a few things... The browser will trigger the requestAnimationFrame roughly 60 times per second in most cases (except when that browser window is inactive) - there's nothing you can do to prevent that (as far as I know), nor should you really care (in my opinion at least). Obviously it's intended to provide hooks for animation systems to run their logic in tandem with the browser's native rendering pipeline. It isn't as though the events are chewing up a bunch of resources or slowing things down significantly. GSAP does indeed tap into the requestAnimationFrame API for maximum performance. It does have one request that keeps going even when there are no active tweens, and that is by design. An explanation can be found here: http://forums.greens...5009#entry25009 You can definitely tap into GSAP's core ticker - that would be much smarter than duplicating code with your own stuff, especially because GSAP automatically falls back to setTimeout() if necessary. Plus it dynamically smooths the frame rate, adjusting the time between refreshes on-the-fly to maximize smoothness. All you need to do is call: TweenLite.ticker.addEventListener("tick", yourFunction); function yourFunction() { //do stuff... } ​Does that clear things up?