Leaderboard

Hello @hh23 and Welcome to the GreenSock Forum! The reason autoAlpha: 0.99 works is due to how the stacking context works in the browser. That puts the element onto a new stacking layer Please see stacking_context spec One of the ways an element will get a new stacking context is when an: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context In IE you can just set transform-style to flat ( transform-style: flat ) Happy Tweening!

Oh, it's great Jack ! Thank you for this quick and very helpful answer. I would never have thought to adjust the autoAlpha to 0.99, incredible. On the latest version of firefox, it actually works with your tips. On IE, you must also disable the css "transform-style: preserve-3d;". A big thank-you.

Very interesting - it looks like this has nothing to do with GSAP but is related to how some browsers "optimize" SVG rendering in certain situations. If you remove the "perspective" that you set on the SVGs, and make autoAlpha go to 0.99 instead of 1 on those same elements, it resolves things (at least in Firefox that I tested it in). So just 2 changes to your code. Most browsers force anything that's got a 3D-related property set (like perspective, rotationX, rotationY, or z) to get rendered on the GPU, thus it creates a texture for it, often at the original raster size and since you're scaling this up to 20x its normal size, things are getting pixelated when that texture is stretched up. The other odd thing was how the browser decided to totally shift the rendering as soon as its opacity was 1 (but 0.99 was fine). Does that help?

Hi and welcome to the GreenSock forums, It sounds like you just want to be able to detect when something that is dragged gets dropped in a certain area. Here is a demo that illustrates those features of Draggable You will see that when you leave a box in the Drop Area that it changes a style (gets a yellow border) at that point you can do whatever you need to: put the element in an array, send a text message, update some value in a form.

Hello @mr.x and Welcome to the GreenSock Forum! The issue is that SVG child elements <symbol> or <defs> element are not directly rendered in the DOM. So they are removed from the browser render tree. But that is part of the SVG spec so it is not advised to try to animate CSS with graphical elements inside a <defs> or <symbol> element, since they wont visually animate! SVG <symbol> spec: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol Note that a symbol element itself is not rendered. Please see this for more info on why https://greensock.com/forums/topic/13681-svg-gotchas/?do=findComment&comment=57408: Better to access the attributes and animate them, or use the GSAP AttrPlugin for this. This is regarding animating SVG elements within an SVG <defs> tag. If you are trying to animate elements within an SVG <defs> element, then you should use the GSAP AttrPlugin. If your SVG elements are not within a SVG <defs>, <symbol>, or <mask> element .. than you should use the GSAP CSSPlugin like your already doing! Which is the default when tweening CSS properties in GSAP. GSAP is smart enough to know when to use what. But for attributes, wrap your attributes in the attr:{} object when using the GSAP AttrPlugin If you are animating SVG elements and they are nested inside a SVG <defs> element. then you need to animate those nested graphical elements with the GSAP AttrPlugin, instead of the GSAP CSSPlugin. The reason being is that Firefox will honor the SVG spec and will follow web standards whereas webkit browsers like Google Chrome and Apple Safari will allow certain non-standards and non-spec behavior. But will later remove that non-standards and non-spec behavior to line up with the spec, further confusing users / developers. SVG Graphics elements are considered the folllowing: <circle>, <ellipse>, <image>, <line>, <path>, <polygon>, <polyline>, <rect>, <text>, <use> That is why i always debug and test in Firefox first knowing the expected behavior will line up with the spec, in this case the SVG spec. And then i debug webkit (Chrome and Safari), followed by debugging IE. Doing it that way I guarantee that HTML, DOM and SVG elements will behave according to the web standards, the spec, and cross browser. CSS is not directly rendered inside a SVG <defs> or <symbol> element. That is why using the GSAP AttrPlugin works, since it animates the attribute values directly. Taken from SVG spec on the MDN (Mozilla Developer Network) website. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs <defs> SVG allows graphical objects to be defined for later reuse. It is recommended that, wherever possible, referenced elements be defined inside of a defs element. Defining these elements inside of a defs element promotes understandability of the SVG content and thus promotes accessibility. Graphical elements defined in a defs will not be directly rendered. You can use a <use> element to render those elements wherever you want on the viewport. The same goes for the nested elements within an SVG <symbol> element. So as rule of thumb when animating SVG, if the element your animating is within a SVG <defs> or <symbol> element , then please use the GSAP AttrPlugin. But if it is not nested inside a <defs> or <symbol> element, then you can use GSAP as usual, knowing that it will use the CSSPlugin instead. You could access the Shadow DOM with web components but its not really ready for prime time. Happy Tweening

Thanks @Jonathan! The "SVG Gotchas section" is such a helpful resource, thank you for all your help there. I've read through it numerous times and I did try the AttrPlugin, but I couldn't figure out how to first access the cloned node's children individually, to apply the animation to, lol. After more research I've come to the conclusion that we can't reliably access the shadow dom. A couple of years ago I was messing around with the webkit pseudo elements which are in the shadow dom, but they are specifically earmarked so it's not the same thing. The shadowroot spec is interesting, but only Chrome seems to support it so far. It's unrelated, but at one point I found an interesting side effect where you can control all the <use> clones simultaneously by animating the <symbol> directly, as demonstrated in this pen: Anyway thanks for all your help!

Thank you also Jonathan for these explanations, it seems clear to me

Here is the demo where you can use relative width.

Deleted incorrect answer. Here is the thread that discusses limitations of use tag, see if it helps.

@Jonathan Nice idea of all docs links in the signature, never occurred to me. Gonna copy yours, saves a lot of time.

Just real quick, I don't know what other code you have there, but rotation can calculated from the velocity. Velocity would just be the change in x and y, so it might look something like this. But that's just a guess. Hard to tell without seeing your other code. var oldX = this.x; var oldY = this.y; this.x += this.speed this.y = this.amp * Math.sin( this.x * this.cycles ) + this.center var dx = this.x - oldX; var dy = this.y - oldY; var rotation = Math.atan2(dy, dx); // in radians

I've been noticing lately that it would be very handy if there was a way to wrap values during a tween, just like the hours on a clock. 9 + 4 hours = 1. I made a demo that does this for positioning, but it's not very performant because it creates a lot of tweens on every update. http://codepen.io/osublake/pen/4d1b3311b08073d0bebfa061a2199e61?editors=0010 Creating something like that could be greatly simplified if there was a way for GSAP to do that internally. A modulo operator has been proposed for a future version of ECMAScript using this syntax. -2 mod 12 So we could use the word "mod" to tell GSAP to run the value through a modulo function before applying the value. TweenLite.to(foo, 1, { x: "800mod600" }); So what's going to happen is that it will tween to 600, go back to 0, and tween to 200. This would make creating carousels/sliders a breeze. var index = 0; $("#prev").click(function() { move(-1); }) $("#next").click(function() { move(1); }) function move(steps) { index += steps; TweenLite.to(".slider", 1, { xPercent: index + "00mod500" }); } Pretty simple! No cloning, calculating positions, or secondary updates required. And because it's position will automatically reset, you can click through the slides as fast you want. The only problem I see with the mod is that it resets the value to 0. This is probably not something you want to happen for something like scaling, so there should be a way to define a base value. Maybe something like this. TweenLite.to(foo, 1, { scale: "2mod0.5+=1" }); Thoughts?

Ok Blake, I officially hate you from the bottom of my lungs. I have spent the whole of last week trying to make one, let me repeat ONE cool animation and I am still not done. In the meantime, you have suggested a new feature, Jack's implemented the idea and you have made who-knows-how-many dozens of different examples. REALLY? And you say you hold a job? And sleep? No way. I haven't even had time to look into what you have been showcasing to be honest. But the plugin is really cool and I can see myself coming up with uses to a get/set (once I am a bit more proficient with the concept). So, *grumble, grumble*, OSUblake is onto something here, Jack.

The correct way to do a sprite sheet animation... using a packed sprite sheet. http://codepen.io/osublake/pen/9304bdc45980d9b47376365cd7ee8fde?editors=0010

Thanks! Using that approach I managed to get an ease out that I'm happy with. In case anyone is interested my exact code was: var rotationTween:TweenMax = TweenMax.to(_mainWheel, 5, {rotation: -degrees, ease: Quad.easeIn}); TweenLite.delayedCall(3.5, slowDown1); TweenLite.delayedCall(5, slowDown2); function slowDown1():void { TweenLite.to(rotationTween, 4, {currentProgress: 1}); } function slowDown2():void { TweenLite.to(rotationTween, 5, {currentProgress: 1, ease: Quart.easeOut, onComplete: onWheelSpinComplete}); }