Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'tweening'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 31 results

  1. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. As the author of GSAP I'm sometimes asked if the Web Animations API (WAAPI) will be used under the hood eventually. My responses have gotten pretty long so I thought I'd share my findings with everyone here. Hopefully this sheds light on the challenges we face and perhaps it can lead to some changes to WAAPI in the future. WAAPI is a native browser technology that's similar to CSS animations, but for JavaScript. It's much more flexible than CSS animations and it taps into the same mechanisms under the hood so that the browser can maximize performance. Support is a bit spotty right now and there are multiple levels to the spec, so some browsers may support only "level 1", for example, but the hope is that eventually all major browsers will support WAAPI fully. Progress in that direction has been very, very slow. You could think of WAAPI almost like a browser-level GSAP with a bunch of features stripped out. This has led some to suggest that perhaps GSAP should be built on TOP of WAAPI to reduce file size and maximize performance. Ideally, people could tap into the rich GSAP API with all of its extra features while benefiting from the browser's native underpinnings wherever possible. Sounds great, right? Unfortunately, WAAPI has some critical weak spots that make it virtually impossible for GSAP to leverage it under the hood (at least in any practical manner). I don't mean that as a criticism of WAAPI. In fact, I really wanted to find a way to leverage it inside GSAP, but I'll list a few of the top reasons why it doesn't seem feasible below. To be clear, this is NOT a feature comparison or a bunch of reasons why GSAP is "better" - these are things that make it architecturally impossible (or very cumbersome) to build GSAP on WAAPI. Custom easing WAAPI only supports cubic-bezier() for custom easing, meaning it's limited to one segment with two control points. It can't support eases like Bounce, Elastic, Rough, SlowMo, wiggle, ExpoScaleEase, etc. GSAP must support all of those eases plus any ease imaginable (unlimited segments and control points - see https://greensock.com/customease). This alone is a deal-breaker. Expressive animation hinges on rich easing options. Independent transform components The most commonly animated values are translation (x/y position), rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving (translate) something and then halfway through start rotating it and stagger a scale toward the end: |-------- translateX() ------------| |------ rotate() ------| |---------- translateY() -----------| |-------------- scale(x,y) --------------| Animators NEED to be able to independently control these values in their animations. Additive animations (composite:"add") probably aren't an adequate solution either. It's unrealistic to expect developers to track all the values manually or assume that stacking them on top of each other will deliver expected results - they should be able to just affect the rotation (or whatever) at any time, even if there was a translate() or scale() applied previously. GSAP could track everything for them, of course, but continuously stacking transforms on top of each other seems very inefficient and I imagine it'd hurt performance (every transform is another matrix concatenation under the hood). There is a new spec being proposed for translate, scale, and rotate CSS properties which would certainly help, but it's not a full solution because you still can't control the x/y components independently, or all of the 3D values like rotationX, rotationY, z, etc. This is an essential feature of GSAP that helped it become so popular. Example See the Pen Independent Transforms Demo by GreenSock (@GreenSock) on CodePen. Custom logic on each tick Certain types of animations require custom logic on each tick (like physics or custom rounding/snapping or morphing). Most GSAP plugins rely on this sort of thing (ModifiersPlugin, for example). I'm pretty sure that's impossible with WAAPI, especially with transforms being spun off to a different thread (any dependencies on JS-based logic would bind it to the main thread). Non-DOM targets As far as I know, WAAPI doesn't let you animate arbitrary properties of generic objects, like {myProperty:0}. This is another fundamental feature of GSAP - people can use it to animate canvas library objects or generic objects...whatever. Global timing controls I don't think WAAPI lets you set a custom frame rate. Also, GSAP's lag smoothing feature requires the ability to tweak the global time (not timeScale - I mean literally the current time so that all the animations are pushed forward or backward). As far as I know, it's impossible with WAAPI. Synchronization (transforms and non-transforms) As demonstrated in this video, one of the hidden pitfalls of spinning transforms off to another thread is that they can lose synchronization with other main-thread-based animations. As far as I know, that hasn't been solved in all browsers. We can't afford to have things getting out-of-sync. Some have proposed that GSAP could just fall back to using a regular requestAnimationFrame loop to handle things that aren't adequately supported by WAAPI but that puts things at risk of falling out of sync. For example, if transforms are running on a separate thread they might keep moving while other parts of the animation (custom properties that get applied somehow in an onUpdate) slow down or jank. Compatibility GSAP has earned a reputation for "just working" across every browser. In order to deliver on that, we'd have to put extra conditional logic throughout GSAP, providing fallbacks when WAAPI isn't available or doesn't support a feature. That would balloon the file size substantially and slow things down. That's a tough pill to swallow. WAAPI still isn't implemented in several major browsers today. And then there are the browser inconsistencies (like the infamous SVG origin quirks) that will likely pop up over time and then we'd have to unplug those parts from WAAPI and maintain the legacy raw-JS mechanisms internally. Historically, there are plenty of cross-browser bugs in natively-implemented technologies, making it feel risky to build on top of. Performance WAAPI has a performance advantage because it can leverage a separate thread whereas JavaScript always runs on the main thread, right? Well, sort of. The only time a separate thread can be used is if transforms and/or opacity are the only things animating on a particular element (or else you run into synchronization issues). Plus there's overhead involved in managing that thread which can also get bogged down. There are tradeoffs either way. Having access to a different thread is fantastic even if it only applies in certain situations. That's probably the biggest reason I wanted to leverage WAAPI originally, but the limitations and tradeoffs are pretty significant, at least as it pertains to our goals with GSAP. Surprisingly, according to my tests GSAP was often faster than WAAPI. For example, in this speed test WAAPI didn't perform as well as GSAP on most devices I tried. Maybe performance will improve over time, but for now be sure to test to ensure that WAAPI is performing well for your animations. File Size To ensure compatibility, GSAP would need all of its current (non-WAAPI) code in place for fallbacks (most browsers won't fully support WAAPI for years) and then we'd need to layer in all the WAAPI-specific code on top of that like conditional logic checking for compatible eases, sensing when the user is attempting something WAAPI can't support, tracking/stacking additive animations, etc. That means file size would actually be far worse if GSAP were built on WAAPI. Some have suggested creating a different adapter/renderer for each tech, like a WebAnimationsAdapter. That way, we could segregate the logic and folks could just load it if they needed it which is clever but it doesn't really solve the problem. For example, some plugins may affect particular CSS properties or attributes, and at some point conditional logic would have to run to say "oh, if they're using the WebAnimationsAdapter, this part won't work so handle it differently". That conditional logic generally makes the most sense to have in the plugin itself (otherwise the adapter file would fill up with extra logic for every possible plugin, bloating file size unnecessarily and separating plugin logic from the plugin itself). So then if anyone uses that plugin, they'd pay a price for that extra logic that's along for the ride. Weighing the Pros & Cons At the end of the day, the list of "pros" must outweigh the "cons" for this to work, and currently that list is quite lopsided. I'd love to find a way to leverage any of the strengths of WAAPI inside GSAP for sure, but it just doesn't seem feasible or beneficial overall. The main benefit I see in using WAAPI inside GSAP is to get the off-the-main-thread-transforms juice but even that only seems useful in relatively uncommon scenarios, and it comes at a very high price. I'm struggling to find another compelling reason to build on WAAPI; GSAP already does everything WAAPI does plus a lot more. I'm hopeful that some of the WAAPI benefits will someday be possible directly in JS so that GSAP wouldn't have to create a dependency on WAAPI to get those. For example, browsers could expose an API that'd let developers tap into that off-the-main-thread transform performance. Ideally, browsers would also fix that hacky matrix()/matrix3d() string-based API and provide a way to set the numeric matrix values directly - that'd probably deliver a nice speed boost. Please chime in if I'm missing something, though. (Contact us or post in the forums) Why use GSAP even if/when WAAPI gets full browser support? Browser bugs/inconsistencies Lots of extra features like morphing, physics, Bezier tweening, text tweening, etc. Infinite easing options (Bounce, Elastic, Rough, SlowMo, ExpoScaleEase, Wiggle, Custom) Independent transform components (position, scale, rotation, etc.) Animate literally any property of any object (not just DOM) Timeline nesting (workflow) GSDevTools Relative values and overwrite management from() tweens are much easier - you don't need to get the current values yourself Familiar API Why WAAPI might be worth a try If you don’t need broad browser support today or any of GSAP’s unique features, you could save some kb by using WAAPI Solid performance, especially for transforms and opacity Always free Again, the goal of this article is NOT to criticize WAAPI at all. I think it's a great step forward for browsers. I just wanted to explain some of the challenges that prevent us from using it under the hood in GSAP, at least as it stands today. EDIT: Brian Birtles, one of the primary authors of the WAAPI spec, reached out and offered to work through the issues and try to find solutions (some of which may involve editing the spec itself) which is great. Rachel Nabors has also worked to connect people and find solutions. Although it may take years before it's realistic to consider building on WAAPI, it's reassuring to have so much support from leaders in the industry who are working hard to move animation forward on the web.
  2. GreenSock

    Ease Visualizer

    The ease-y way to find the perfect ease A solid mastery of easing is what separates the top-notch animators from the hacks. Use this tool to play around and understand how various eases "feel". Notice that you can click the underlined words in the code sample at the bottom to make changes. Some eases have special configuration options that open up a world of possibilities. If you need more specifics, head over to the docs. Quick Video Tour of the Ease Visualizer A special thanks to Jamie Barlow who built almost the entire thing. He's one of our all-stars in the forums, lending his wisdom and animation prowess to our whole community. He's a rock star. Take your animations to the next level with CustomEase CustomEase frees you from the limitations of canned easing options; create literally any easing curve imaginable by simply drawing it in the Ease Visualizer or by copying/pasting an SVG path. Zero limitations. Use as many control points as you want. Grab CustomEase below or find out more.
  3. GreenSock

    CustomEase

    Are your animations meant to feel playful? Robotic? Slick? Realistic? If they had a voice, what would they sound like? To become an animation rock star, you must develop a keen sense of easing because that's what determines the style of movement between point A and point B. GreenSock's new CustomEase frees you from the limitations of canned easing options. Create literally any ease imaginable. Zero limitations. Note that the video is using GSAP 2 format. CSS animations and WAAPI offer cubic-bezier() which is great but with only two control points it's impossible to create more complex effects like bouncing, elastic, wiggles, rough/jerky eases, etc. Plus you can't make an ease return to its starting values (like a ball jumping into the air and falling back to the ground with a bounce). Features Unlimited anchors and control points. Copy/Paste any SVG <path> (including directly from Adobe Illustrator). Use CSS cubic-bezier() values (For example, from cubic-bezier.com). Editor has snapping, undo, sample code and other conveniences. Start with any standard ease and customize it. getSVGData() method turns any ease into SVG <path> data for display at the size you define. Extremely optimized for runtime performance. Free for anyone with a GreenSock account. Reading Ease Curves, Editing, and Using CustomEase Here's an in-depth video tour that'll get you up to speed with exactly how to use CustomEase (note that the video is using GSAP 2 format): Ready to play? Check out the new Ease Visualizer with CustomEase support. Edit the curve as much as you want: Download CustomEase Get CustomEase by creating a FREE GreenSock account which gets you access to our community forums plus you’ll receive our exclusive “GreenSock Insider” email series (you can unsubscribe anytime). Use the widget below to sign up (or if you’re already logged in, you’ll get immediate access to the download zip containing CustomEase). Note: CustomEase is not in the GitHub repository or CDN; it's only available for download at GreenSock.com.
  4. GreenSock

    TweenMax

    Note: TweenMax has been deprecated in GSAP 3 (but GSAP 3 is still compatible with TweenMax). We highly recommend using the gsap object instead. While GSAP 3 is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. TweenMax is the most feature-packed (and popular) animation tool in the GSAP arsenal. For convenience and loading efficiency, it includes TweenLite, TimelineLite, TimelineMax, CSSPlugin, AttrPlugin, RoundPropsPlugin, BezierPlugin, and EasePack (all in one file). Quick links Getting started What's so special about GSAP? Full documentation Showcase (examples) Since TweenMax extends TweenLite, it can do ANYTHING TweenLite can do plus more. You can mix and match TweenLite and TweenMax in your project as you please. Like TweenLite, a TweenMax instance handles tweening one or more properties of any object (or array of objects) over time. TweenMax's unique special properties TweenMax's syntax is identical to TweenLite's. Notice how the TweenMax tween below uses the special properties: repeat, repeatDelay, yoyo and the onRepeat event callback. //basic illustration of TweenMax's repeat, repeatDelay, yoyo and onRepeat var box = document.getElementById("greenBox"), count = 0, tween; tween = TweenMax.to(box, 2, {left:"740px", repeat:10, yoyo:true, onRepeat:onRepeat, repeatDelay:0.5, ease:Linear.easeNone}); function onRepeat() { count++; box.innerHTML = count; TweenLite.set(box, {backgroundColor:"hsl(" + Math.random() * 255 + ", 90%, 60%)"}); } See the Pen TweenMax basic repeat and onRepeat by GreenSock (@GreenSock) on CodePen. Staggered animations TweenMax makes it easy to create staggered animations on multiple objects. The animations can overlap, run in direct sequence or have gaps between their start times. TweenMax's three stagger methods: TweenMax.staggerTo(), TweenMax.staggerFrom() and TweenMax.staggerFromTo() are literal one-line wonders. See the Pen TweenMax.staggerTo() by GreenSock (@GreenSock) on CodePen. Additional Methods TweenMax inherits a ton of methods from TweenLite and has quite a few of its own. ul.chart {width:300px; float:left; margin-right:80px; } ul.chart li:nth-child(1){ font-weight:bold; list-style:none; margin-left:-20px; font-size:20px; margin-bottom:20px; } TweenLite and TweenMax Methods delay() delayedCall() duration() eventCallback from() fromTo() getTweensOf() invalidate() isActive() kill() killDelayedCallsTo() killTweensOf() pause() paused() play() progress() restart() resume() reverse() reversed() seek() set() startTime() time() timeScale() to() totalDuration() totalProgress() totalTime() Methods exclusive to TweenMax getAllTweens() isTweening() killAll() killChildTweensOf() pauseAll() repeat() repeatDelay() resumeAll() staggerFrom() staggerFromTo() staggerTo() updateTo() yoyo() Learn more in the TweenMax documentation.
  5. GreenSock

    GSDevTools

    Your animation workflow is about to get a major boost. GSDevTools gives you a visual UI for interacting with and debugging GSAP animations, complete with advanced playback controls, keyboard shortcuts, global synchronization and more. Jump to specific scenes, set in/out points, play in slow motion to reveal intricate details, and even switch to a "minimal" mode on small screens. GSDevTools makes building and reviewing GSAP animations simply delightful. Get Started Load the JavaScript file //be sure to use a path that works in your dev environment Requirements GSDevTools requires TweenMax (well, actually just CSSPlugin, TweenLite, TimelineLite, AttrPlugin which are all included in TweenMax) version 1.20.3 or higher. It also uses Draggable under the hood, but in order to minimize hassle for end users, Draggable is included inside the GSDevTools file itself. How do I get it? GSDevTools is available to Club GreenSock members ("Shockingly Green" and above). Just download GSAP with the bonus files zip from your Dashboard. Try GSDevTools for free on CodePen. FAQ Why is my Global Timeline 1000 seconds long? That means you've probably got an infinitely repeating animation somewhere. GSDevTools caps its duration at 1000 seconds. Scrubbing to Infinity is awkward. Does loading GSDevTools impact runtime performance? Since it must monitor and record the root timeline, yes, there is a slight performance hit but probably not noticeable. Keep in mind that usually you'll only load GSDevTools while you're developing/reviewing your animations and then remove it when you're ready to launch, so ultimately it shouldn't be much of a factor anyway. Why isn't GSDevTools in the CDN or Github repo? Because it's a membership benefit of Club GreenSock. It's a way for us to give back to those who support our ongoing development efforts. That's why we've been able to continue innovating for over a decade. See https://greensock.com/why-license for details about our philosophy. Does GSDevTools work with other animation libraries? Nope, it depends on some unique capabilities baked into the GSAP architecture. What will I do with all the time this tool saves me? Take up a new hobby, ponder deep philosophical questions, make cookies - it's up to you.
  6. Scrambles the text in a DOM element with randomized characters (uppercase by default, but you can define lowercase or a set of custom characters), refreshing new randomized characters at regular intervals while gradually revealing your new text (or the original text) over the course of the tween (left to right). Visually it looks like a computer decoding a string of text. Great for rollovers. See the Pen GSAP Scramble Text Plugin - feature plugin page by GreenSock (@GreenSock) on CodePen. You can simply pass a string of text directly as the scrambleText and it'll use the defaults for revealing it, or you can customize the settings by using a generic object with any of the following properties: text : String - The text that should replace the existing text in the DOM element. If omitted (or if "{original}"), the original text will be used. chars : String - The characters that should be randomly swapped in to the scrambled portion the text. You can use "upperCase", "lowerCase", "upperAndLowerCase", or a custom string of characters, like "XO" or "TMOWACB", or "jompaWB!^", etc. (Default: "upperCase") tweenLength : Boolean - If the length of the replacement text is different than the original text, the difference will be gradually tweened so that the length doesn't suddenly jump. For example, if the original text is 50 characters and the replacement text is 100 characters, during the tween the number of characters would gradually move from 50 to 100 instead of jumping immediatley to 100. However, if you'd prefer to have it immediately jump, set tweenLength to false. (Default: true) revealDelay : Number - If you'd like the reveal (unscrambling) of the new text to be delayed for a certain portion of the tween so that the scrambled text is entirely visible for a while, use revealDelay to define the time you'd like to elapse before the reveal begins. For example, if the tween's duration is 3 seconds but you'd like the scrambled text to remain entirely visible for first 1 second of the tween, you'd set revealDelay to 1. (Default: 0) newClass : String - If you'd like the new text to have a particular class applied (using a <span> tag wrapped around it), use newClass:"YOUR_CLASS_NAME". This makes it easy to create a distinct look for the new text. (Default: null) oldClass : String - If you'd like the old (original) text to have a particular class applied (using a <span> tag wrapped around it), use oldClass:"YOUR_CLASS_NAME". This makes it easy to create a distinct look for the old text. (Default: null) speed : Number - Controls how frequently the scrambled characters are refreshed. The default is 1 but you could slow things down by using 0.2 for example (or any number). (Default: 1) delimiter : String - By default, each character is replaced one-by-one, but if you'd prefer to have things revealed word-by-word, you could use a delimiter of " " (space). (Default: "") //use the defaults gsap.to(element, {duration: 1, scrambleText:"THIS IS NEW TEXT"}); //or customize things: gsap.to(element, {duration: 1, scrambleText:{text:"THIS IS NEW TEXT", chars:"XO", revealDelay:0.5, speed:0.3, newClass:"myClass"}});
  7. GreenSock

    GSAP 2.0 Released

    Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. We've been getting requests for better support of modern build tools. With version 2.0 we're pleased to announce a switch to ES modules via NPM which should make your building, bundling, and tree shaking even smoother. Don't worry, the UMD/CommonJS flavor is still available and the CDN serves the same browser-friendly files as always. If terms like "UMD", "ES Modules", and "tree shaking" leave you scratching your head, fear not - GSAP 2.0 will work like a champ for you (as usual). There are no syntax, API, or browser-support changes. None. The major version bump was primarily due to the switch to ES modules for NPM users, that's all. DOWNLOAD GSAP NOW NPM, ES Modules, Webpack, oh my! Modern bundlers like Webpack and Rollup just love to snack on ES modules these days, usually grabbing them from NPM. So GSAP 2.0 is extra delicious covered in its chocolatey ES module outer shell. (If you're not using a bundler or NPM, skip this section entirely) npm install gsap Then you can import individual classes like: import TweenMax from "gsap/TweenMax"; import Draggable from "gsap/Draggable"; TweenMax includes (and exports) many of the commonly-used classes so you can also do this: import { TweenMax, TimelineLite, Power2, Elastic, CSSPlugin } from "gsap/TweenMax"; (TweenMax includes TweenLite, TimelineLite, TimelineMax, CSSPlugin, RoundPropsPlugin, BezierPlugin, DirectionalRotationPlugin, AttrPlugin, and all eases except CustomEase, CustomWiggle, and CustomBounce) As a convenience, there's also an "all" file that imports/exports every GSAP tool (except members-only bonus plugins), so you can do this: import { TimelineMax, CSSPlugin, ScrollToPlugin, Draggable } from "gsap/all"; IMPORTANT: if your animations aren't working as expected, it's likely an issue with tree shaking which can be easily resolved by referencing any plugins you're using. Read more. UMD/CommonJS If your environment doesn't accommodate ES modules yet, don't worry - we've got you covered. There's a "umd" directory that contains...you guessed it...regular old ES5 UMD (Universal Module Definition) versions of the files which are compatible with pretty much everything (RequireJS, Browserify, etc.). So you could import them like: //get the UMD versions. Notice the "/umd/" in the path... import { TweenMax, Power2, TimelineLite } from "gsap/umd/TweenMax"; import ScrollToPlugin from "gsap/umd/ScrollToPlugin"; import Draggable from "gsap/umd/Draggable"; What about bonus plugins like MorphSVGPlugin? Obviously we can't distribute the members-only bonus plugins via NPM, so all you need to do is log into your GreenSock account and download the latest zip which has a "bonus-files-for-npm-users" folder with the bonus plugins. Then just plop that into your project, like maybe in your /src/ folder (or wherever) and import them directly. For example, to save some typing you could rename the "bonus-files-for-npm-users" to simply "gsap-bonus" and put that in the root of your project and then: import MorphSVGPlugin from "./gsap-bonus/MorphSVGPlugin"; import SplitText from "./gsap-bonus/SplitText"; You could certainly put the bonus files in /node_modules/gsap/ if you prefer, but most people don't like doing that because it makes things less portable/updatable. There's a brand new page in the docs dedicated to NPM usage. NEW: Custom rounding increments in RoundPropsPlugin Have you ever needed to round animated values to the nearest 10 or hundredth? With the new object syntax in RoundPropsPlugin, you can round properties to various custom increments, not just integers! Simply pass in [property]:[increment] pairs like so: TweenLite.to(element, 5, { x:600, y:100 roundProps:{ x:10, //round x to nearest increment of 10 y:0.1 //round y to nearest increment of 0.1 } }); Watch the video Demo See the Pen RoundPropsPlugin Update by GreenSock (@GreenSock) on CodePen. NEW: SplitText "specialChars" SplitText recognizes a new specialChars property that allows you to specify an array of special characters to protect. This is typically used for multi-character symbols like in some languages where there are pairs (or sometimes even 4 characters) combined to form a single character. See the Pen SplitText with specialChars feature by GreenSock (@GreenSock) on CodePen. No need to do this for most emoji's, though, because those are already supported natively in SplitText! Got questions? If you haven't checked out the forums, you're missing out! It's a great place to get your questions answered and participate in the community. We carefully monitor and answer questions there. Or feel free to contact us directly if you prefer. Changelog View the full changelog here (note: version 2.0.0 is just 1.20.5 with a version bump to avoid breaking changes for NPM users) Happy tweening! DOWNLOAD GSAP NOW
  8. GreenSock

    GSAP 1.20.0 Released

    Here are some of the highlights of the GSAP 1.20.0 release... yoyoEase Now you can specify an ease for the yoyo (backwards) portion of a repeating TweenMax animation. Set it to a specific ease like yoyoEase:Power2.easeOut or to flip the existing ease, use the shortcut yoyoEase:true. TweenMax is smart enough to automatically set yoyo:true if you define a yoyoEase, so there's less code for you to write. Score! Animate CSS Variables (custom properties) See the Pen CSS Variables Demo by GreenSock (@GreenSock) on CodePen. Emoji support in TextPlugin 'Nuf said. ...and more There are quite a few little improvements and bug fixes as well, which are listed in the changelog at the github repository. Download GSAP today. Happy tweening!
  9. GreenSock

    Introducing CustomEase

    Are your animations meant to feel playful? Robotic? Slick? Realistic? If they had a voice, what would they sound like? To become an animation rock star, you must develop a keen sense of easing because that's what determines the style of movement between point A and point B. GreenSock's new CustomEase frees you from the limitations of canned easing options. Create literally any ease imaginable. Zero limitations. CSS animations and WAAPI offer cubic-bezier() which is great but with only two control points it's impossible to create more complex effects like bouncing, elastic, wiggles, rough/jerky eases, etc. Plus you can't make an ease return to its starting values (like a ball jumping into the air and falling back to the ground with a bounce). Features Unlimited anchors and control points. Copy/Paste any SVG <path> (including direct copy/paste from Adobe Illustrator). Use CSS cubic-bezier() values (For example, from cubic-bezier.com). Editor has snapping, undo, sample code and other conveniences. Start with any standard ease and customize it. getSVGData() method turns any ease into SVG <path> data for display at the size you define. Extremely optimized for runtime performance. Free for anyone with a GreenSock account. Reading Ease Curves, Editing, and Using CustomEase Here's an in-depth video tour that'll get you up to speed with exactly how to use CustomEase: Ready to play? Check out the new Ease Visualizer with CustomEase support. Click "Custom" to edit the curve as much as you want: Simple Example See the Pen Video: Single Tween with CustomEase by GreenSock (@GreenSock) on CodePen.&#13;We strongly recommend creating your CustomEases initially (rather than in each tween) to maximize performance and readability. You then reference them by ID in your tweening code. When an ease is created, it must parse through the points and do various calculations to prepare for blisteringly fast runtime performance during the animation, so executing those calculations when your page/app loads is typically best. Download CustomEase To get CustomEase, you must have a GreenSock account which is completely free to set up. Plus it gets you access to our community forums (a fantastic place to learn and get your questions answered). The widget below lets you sign up or if you're already logged in, it'll give you immediate access to the download zip that contains CustomEase in the "easing" directory. Note: CustomEase is not in the github repository or CDN; it's only available for download at GreenSock.com. [loginwidget]
  10. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. Have you ever wondered why GreenSock doesn't use a more common open source license like MIT? Sometimes our licensing model is misunderstood but hopefully after reading this article you'll see why it is so foundational to the success of our tools and why it ultimately benefits users too. Open source is awesome! If you had to write and maintain your own jQuery or React or GSAP, could you do it? Would it be as refined and reliable? Probably not. How many times have you found a library or chunk of code on github that saved you hours of development time? Open source can be a quick path to great results. It also serves as a jumping-off point for up-and-coming developers to share their innovation, inspiring others to write better code. Open source is easily one of the most influential movements in the entire development community. We're certainly not anti-open-source. Quite the contrary. Open source is *not* always awesome Despite its strengths, there are some dark sides to open source. Many projects are riddled with bugs, poorly documented, and sometimes even dangerous to use. The web is littered with abandoned projects that once seemed promising. It's like a clearance bin you'd find at a discount store; there may be some treasures in there, but you'll have to dig through a lot of undesirables to find the gems. In an industry that's inundated weekly with "hot new" libraries, all just a click away for free, it can be tough to figure out which ones to gamble on. Commitment required(?) Some libraries are one-trick ponies that don't require ongoing commitment. For example, a math library that performs matrix operations or a formatting library. If the author abandons the project, it's no big deal. Other projects, like a full-featured animation library, are much more complex and leverage browser-level optimizations that are moving targets. Vendor-specific bugs need to be worked around or new browser features get introduced that beg to be animated. Plus, animation is the most performance-sensitive aspect of the user experience, so a commitment to ongoing optimization pays dividends. Beyond the code itself, what about community, documentation and examples? These become increasingly important as a library's feature set expands and companies standardize on it, needing to train new staff. Again, some projects have very little need for ongoing support but for GreenSock, it seemed essential. Hampered by success Paradoxically, success is the very thing that kills many open source projects because they don't have a funding mechanism to underwrite all the demands. The project that was once the twinkle in the author's eyes often ends up being a thorn in their side. They can't afford (or don't really want) to keep up with the demands. That's not to say that all open source projects suffer this fate. We have the utmost respect for open source authors, and we don't mean to diminish anyone's hard work or generosity. But there are some common frailties of open source projects in general that GreenSock aims to avoid. Having built and maintained a popular library for over a decade, we've learned that one of the most important factors in keeping a complex project like GSAP vibrant is the licensing model. Our goal was to make GreenSock tools not only accessible (which MIT does a great job of), but also sustainable, business-friendly, consistent, and respectful. We needed a license that would have the best chance of facilitating those goals, as described below: Sustainable Scores of animation libraries have come and gone over the years. We didn't want to be just another flash in the pan that ultimately leaves users feeling abandoned. Trust is paramount for us. We wanted the GreenSock brand to be associated with an exceptionally high level of commitment and reliability. Earning that trust requires a consistent, full-time effort so we considered these funding models: Self-funded - most open source projects are self-funded, meaning that the authors cover all the costs themselves, typically by donating their time and resources. It's noble and perfectly adequate for many projects. An MIT (or similar) license is a great fit because it allows an author to share code with almost zero strings attached. However, the commitment level tends to be unreliable and self-funded projects are rarely sustained long-term. With our particular project and goals, this wasn't a good fit. Corporate sponsorship - sometimes huge companies like Adobe, Microsoft, Facebook, or Google are willing to contribute funds to encourage a project. They usually have a vested interest in its success. For example, Adobe helps fund CreateJS which is a set of libraries that its very own Adobe Animate (formerly Flash) relies on. React is underwritten by Facebook. This can be a great way to offload development costs onto some deep-pocketed corporations, keeping it totally free for end users. The risk, however, is that if the project goals don't line up with the corporation's agenda (which can shift), funding gets yanked or the developers get pressured to go in a direction that may not be good for end users. If the company has a bad year, they may re-allocate resources. The project is ultimately beholden to a few key sponsors with potentially conflicting objectives. This wasn't something we were comfortable with although we acknowledge that it's a great solution for certain projects. Private investors - famo.us is probably the most well-known example of an "open source" project that took on private investors. A few years and $30,000,000+ later, it stopped development of its open source library and laid off a large chunk of its staff, deciding to "pivot" in a more profitable commercial direction. Private investors want a return on their investment (which is completely understandable) but an MIT license can make that very difficult because it leaves the IP (intellectual property) wide open for anyone to steal, including competitors. Similar to corporate sponsorship, projects who get their funding this way are beholden to a few key stakeholders who may have a very different agenda than end users. Again, this wasn't an ideal fit for GreenSock. User-funded - when funding comes directly from end users, it creates a wider base (more stable) and incentivizes the kind of innovation that end users actually care about, otherwise funding naturally dries up. That's a healthy dynamic for aligning agendas. Rather than serving a small set of outside investors looking for a return or a corporation with profit centers to bolster, end users play the central role. The downside, of course, is that certain features or use cases involve a fee. That can be a tough pill to swallow for some, especially when "free" MIT-licensed options abound. And it takes time to build up a wide base of users who literally "buy in". Trust and longevity are key. But a surprising number of users embrace this model because it allows them to "vote" with their dollars and participate in making a product they love continue to thrive. While this model certainly isn't for everyone, it has been a good fit for GreenSock. Accessible Sometimes we hear comments like "you can't use GreenSock in commercial projects without a license." WRONG. [loud buzzer noise]. Our license was designed to make the tools extremely accessible, even permitting usage in one-off commercial projects (where you get paid a one-time fee by a single client). And of course it's free to use in non-commercial projects (see licensing page for details). That way, a certain breed of power-user provides the funding that benefits everyone. An estimated 95%+ of our users never pay us a dime. So while a rare type of commercial project does require a "Business Green" Club GreenSock membership (which covers an unlimited number of projects while active), the vast majority of users never need that special license. This accessibility was a cornerstone of our approach. We didn't want to hide all the tools behind an intimidating paywall or make all commercial uses trigger a fee. Yet it couldn't be as unrestrained as MIT because that would create vulnerabilities for us and our users (as described in this article). Another way we keep the core tools accessible is by freely exposing the raw source code both on github and in our downloads. Users can peek under the hood and see how things work. That makes troubleshooting and learning much easier. We tried to strike a balance of openness and healthy insulation from the frailties of MIT. Business-friendly Most businesses are very concerned about IP infringement, lawsuits, and indemnification. The "no strings attached and no warranties" nature of MIT is both a strength and a weakness. It simplifies sharing, but what if an open source library leverages someone else's IP? What if it uses "copyleft" code that infects anything it touches, requiring that all projects using it be open-sourced as well? That could be a huge problem for businesses with proprietary tools in a competitive market. GreenSock's license doesn't have any attribution requirements, nor does it impose share-alike rules like GNU and Creative Commons. Furthermore, it contains warranties that aren't found in MIT-like licenses, making GreenSock more business-friendly. It survived the software audits and legal review process at reputable companies like Google, Sony, EA, Intel, every major ad network, and many others. This vetting is necessary in the business world where there is so much at stake. The license also allows for code edits to be made for bug fixes. Typically that's not necessary because we handle it as a part of our ongoing support efforts, but businesses appreciate knowing that if we relaxed those efforts, they'd still be able to get their project working if they ran into a bug and needed to squash it themselves. Consistent MIT-licensed projects spread on github where it's trivial to fork them and start making custom flavors. That's ideal for authors whose goal is to start something and then step back to let the community run with it. But that can lead to a lot of confusion as different flavors start popping up with incongruent feature sets and incompatibilities. Focus and direction are easily lost. If there's no driver (or too many drivers), it can be a scary ride for the passengers. We wanted the GreenSock brand to convey a certain level of consistency and reliability. That's part of the reason we don't generally accept pull requests - we keep a tight reign on the codebase so that we are intimately aware of every piece. That allows us to not only support it, but also stand behind our IP warranties. Respectful We believe that if we respect our users, they'll generally reciprocate that respect. Most people want to do the right thing. So we don't inject "phone home" code that reports usage or causes things to suddenly stop working when a membership expires. We don't force business customers register each user or enter serial numbers to activate seats. We don't limit installations or the number of projects that the license covers. We don't burn extra energy policing usage. We've never sued anyone. We funnel our energy into refining the tools, innovating, educating, and supporting our users. We put a lot of effort into creating a positive, respectful culture in the forums which boast over 50,000 members and 80,000 posts. We don't charge a dime for support there, and we don't shamelessly promote Club GreenSock memberships. Again, we trust that if we keep trying to provide value, people will notice and gladly sign up to support the efforts at some point. An unintended benefit of our licensing model has been that it naturally weeds out users who expect everything for free and don't recognize the substantial effort that goes into these projects. We're left with users who tend to be very respectful and trustworthy (exactly who we like to serve). Conclusion GreenSock isn't the typical open source project. Our licensing model reflects that. It offers a blend of sustainability, accessibility, business-friendliness, consistency, and respect that'd be very difficult (or impossible) to accomplish with an MIT-like license. It's not necessarily "better" (open source is fantastic, really) but in our particular case it aligned more closely with the project goals. In fact, many companies have chosen GreenSock because of the license, not in spite of it. They wanted to invest in a platform that had a certain level of commitment behind it that's rare in the open source world. After a decade, the experiment seems to be working and we have our supporters to thank for that. We've been humbled and inspired by Club GreenSock members throughout the years. It's a privilege to create these tools and serve the community. We're grateful for their partnership which makes it all possible.
  11. Published: 2015-08-07 Google sparked an urgent and rather violent shift away from Flash technology when it announced that Chrome will pause "less important" Flash content starting as early as September 2015. Flash has served as the de facto standard for banner ads for more than a decade. Firefox also blocked Flash after major security issues were discovered and Facebook's security chief called for Adobe to kill Flash once and for all. Amazon says it will no longer accept any Flash ads after September 1. Clearly Flash is on its way out of web browsers. Advertisers can no longer afford its liabilities. Now what? Modern browsers are remarkably capable of handling slick animations natively using HTML, JavaScript, and CSS (collectively referred to as “HTML5” or just “H5”), making them the obvious choice as the tag-team successor to Flash. No more plugins. However, a few barriers are clogging up the transition. Some are technical, some are political, and some have to do with a glaring lack of information. Let's address things head-on, identify some solutions, and get things moving in the right direction. GreenSock has a rich heritage in the banner ad industry, serving as its most popular animation library in both Flash and HTML5. In fact, it’s one of the fastest-growing JavaScript tools on the entire Internet and it was originally born out of banner-specific needs. We obsess about animation in the browser, studying the technical challenges, performance benchmarks, and workflow. Consequently, we’re in a unique position to lend a hand during this transition and perhaps illuminate the path forward. 40 kilobytes? Are you kidding? Years ago, when bandwidth was a tiny fraction of what it is today, the ad industry codified a set of standards for banner ad file sizes. A common limit was 40kb (sometimes even 30kb) including all images, fonts, animations and scripts which Flash compressed into a single amazingly small swf file. Technically each publisher determines its own file size policies, but almost everyone looks to the IAB (Interactive Advertising Bureau) as a standards-setting body, like the W3C for web browsers. The IAB exists to help guide the industry but they don't mandate or enforce anything. When Flash ruled the banner ad landscape, certain file size specs were recommended by the IAB and the system worked well. However, the technology landscape has changed drastically. Bandwidth, page size, and banner budget over the yearsBandwidth (Mbps)Banner budget (kb)Page size (kb)2008200920102011201220132014201540kb33Mbps40kb1,795kb Year Bandwidth (Mbps) Banner budget (kb) Page size (kb) Jan 1, 2008 5.86 40 312 Jan 1, 2009 6.98 40 507 Jan 1, 2010 9.54 40 679 Jan 1, 2011 10.43 40 788 Jan 1, 2012 12.7 40 1081 Jan 1, 2013 15.62 40 1529 Jan 1, 2014 20.83 40 1622 Jan 1, 2015 32.78 40 1795 Page size (kb) Since 2008, average bandwidth has grown by a factor of 5.6 which is remarkably on-pace with the growth of the average web page size (5.7), but the IAB has been cautious about declaring HTML5 specs due to all the complexities involved. They released a set of HTML5 guidelines in 2013, but omitted any file size specs, saying only that HTML5 ads weigh "more" than swf ads. Without specs, many publishers clung to the safe limits of yesteryear. The gatekeepers who impose the 40kb budgets often do not have the authority or wherewithal to allow more than what the latest IAB spec dictates. Consequently, developers are forced to shoehorn HTML5 banners into archaic Flash specs which isn't what the IAB intended. This must change. From our vantage point, fear is driving the industry. Publishers and networks are afraid to raise the file size limits without IAB approval. Some do it anyway, but disagree on exactly how much, leading to wild variations. Developers have no choice but to build for the least common denominator in their ad campaign which is either totally unclear or ends up being the dreaded creativity-crushing 40kb. (UPDATE: The IAB released a draft of its new HTML5 specs.) HTML5 is fundamentally different...embrace that HTML5 banners often weigh 3-5 times as much as a Flash swf but far too many people myopically focus on the aggregate total file size. They miss the unique strengths of HTML5 technology that we should be exploiting - shared resources and browser caching. These have a tremendous impact on loading time and overall performance which is the whole point of the file size limits anyway! Flash compiled all assets into a single swf meaning that if 10 different banners on a site all used a certain library, it got baked into each and every swf. End users paid the file size price 10 times. Multiply that by millions of ads and it gets pretty crazy. In HTML5, however, a library can be dropped onto a CDN (content delivery network) and shared among all banners, thus end users only load it once and it’s completely "free" thereafter...for all ads pointing at that CDN...on all sites. This is a BIG deal. It means that common animation chores like the requestAnimationFrame loop, timing, sequencing, intelligent GPU layerizing, lag smoothing, compatibility workarounds, performance optimization, etc. can be extracted and shared among them all (much like what the Flash Player did for swf files). The unique banner-specific code can be much more concise, reducing overall load times and improving performance. File size limitations should be applied to the banner-specific assets, excluding the shared resources that drive common functionality. Imagine how silly it would have been if the 17MB Flash Player download was included in the aggregate file size for each swf banner. Ad networks and publishers can put a certain subset of tested-and-approved libraries onto their CDNs and exempt them from file size calculations. We're thrilled to see industry leaders like Advertising.com/AOL, Google DoubleClick, Flashtalking, and Sizmek already taking this approach with GSAP. This strategy allows developers to avoid burning hours manually cooking up their own proprietary libraries to fit within the ad specs. Ad networks and publishers win because load times (and costs) are lowered and it's easier to troubleshoot problems when a common toolset is used. They reap the benefits of all the compatibility and performance optimizations in tools like GSAP. End users get ads that perform better, load faster, and look more appealing. Animation technologies and approaches For those tasked with building HTML5 banners, the choices are perplexing. Is it best to use a visual IDE like Adobe Edge Animate, Google Web Designer, or Tumult Hype? Even Flash is capable of outputting HTML5 content. These tools can make building ads easier (especially for designers who don’t want to write code), but a common complaint is that the resulting output is bloated and slow, making them ill-suited for banner ads. Some networks explicitly state that they won't accept ads built with these tools. We'd love to see the visual tools mature and export concise, performant, ad-friendly code because plenty of designers aren't comfortable hand-coding banners yet. Ideally, they'd tap into GSAP under the hood so that designers and developers could collaborate on the same files without worrying about runtime redundancies. There are also network-specific banner-building tools but their proprietary nature makes them impractical for many campaigns. If an agency uses one network’s proprietary tool and then their client asks to run the ad on another network too, it must be rebuilt. Learning how to use each network's proprietary tool can be cumbersome. Hand-coded animations are usually much lighter-weight, performant, and universally accepted, but building them requires a particular skill set. And which underlying technologies should be used? CSS animations? jQuery? GSAP? CreateJS? Once again, answers vary wildly among ad networks and publishers. The goal of this article isn't to provide an in-depth review or comparison of the various tools. Each has its own strengths and weaknesses, but let's briefly touch on some of the major runtime animation technologies: CSS transitions and CSS animations - these are supported in all modern browsers, but not IE9 or earlier. They're cheap from a file size standpoint and they perform well. For simple animations like button rollovers, they're great. However, file size rises quickly and things get cumbersome when you attempt even moderately complex animations. Simply put, they will take longer to build, they won't work in some older browsers, there are bugs (particularly when animating SVG elements), and certain tasks are outright impossible. Additional reading: https://css-tricks.com/myth-busting-css-animations-vs-javascript/ and http://greensock.com/transitions/ and https://css-tricks.com/svg-animation-on-css-transforms/ jQuery - it was never intended to be a robust animation tool, so jQuery suffers from poor performance and workflow issues. Most ad networks strongly advise against using it. GSAP is up to 20x faster. Additional reading: http://greensock.com/jquery/ CreateJS - Adobe Flash can optionally export to this canvas-based library. You can't just publish existing Flash banners to CreateJS (you must do some conversion work and leverage JavaScript instead of ActionScript) but for designers who are already used to the Flash interface, this can be a boon. One down side to canvas-based libraries is that you lose accessibility (the browser sees it as essentially a blob of pixels), but that's probably not a top priority for banners. File size can also become a concern (possibly mitigated by CDN standardization). You can use GSAP to animate CreateJS content. Additional reading: http://createjs.com Zepto - like a lightweight version of jQuery that uses CSS transitions under the hood for animations. Zepto is better than jQuery for banners, but it suffers from similar workflow issues as well as the inconsistencies/bugs inherent in CSS transitions/animations (like with SVG transforms). Active development seems to have stalled. Additional reading: http://zeptojs.com Web Animations - a new spec being worked on that has a lot of promise, but it just isn't a realistic contender at this point because it is in flux and several browser vendors remain noncommittal about ever supporting it. The polyfill has performance problems. Additional reading: http://w3c.github.io/web-animations GSAP - Widely recognized as the performance leader, GSAP solves all kinds of real-world animation problems from browser inconsistencies to workflow headaches (far too many to go into here). The Flash banner ad community is full of designers and developers who use GSAP daily, making it much easier to transition to HTML5; no new syntax to learn. Ongoing development and support have a solid track record for over 7 years. Additional reading: http://greensock.com/why-gsap/ Recommendations Based on our experience and the results from our survey, we suggest the following: Standardize a few JavaScript libraries Ideally, the IAB would equip the community with a short list of recommended libraries that get CDN-ified and exempted from file size calculations. Historically, the IAB has been extremely reluctant to officially endorse any third party tools. That's understandable - it could be seen as playing favorites or unfairly excluding someone's favorite library. However, without specific recommendations, the HTML5 landscape is so fractured and complex that it will result in a free-for-all (which is basically what it is now). The IAB can set the tone and move the focus away from aggregate total file sizes and into the modern era that leverages shared resources and browser caching to deliver excellent performance. It is imperative that this list of "recommended" libraries be very short, otherwise the caching impact will be diluted. The IAB can run their own independent tests and look at performance, features, compatibility, support, workflow benefits, and overall industry demand to determine which libraries get recommended. Of course we feel strongly that GSAP belongs on that list because: It is the top performer. It has widespread industry acceptance, both in Flash and HTML5. It's recommended by Google, used by the biggest brands in the world, etc. It is framework-agnostic, super flexible and robust, able to animate anything. It is professionally supported, yet free to use in banner ads. Modernize file size specs Given the 5.6x growth factor of bandwidth and page size since 2008, it seems entirely reasonable to adjust the old 40kb limit to 200kb (5x) for the modern HTML5 era. This is entirely consistent with some in-depth testing that has been done recently aimed at identifying the file size threshold at which real-world users perceive a dip in performance. The results showed that the threshold was upwards of 250kb. Combined file size isn't the only issue that contributes to slow load times; the number of server requests can have a significant impact. A single 300kb file can often load faster than 200kb split among 20 files. HTML5 banners can't realistically mash everything into one file, though. Doing so would kill the benefits of caching and resource sharing. So a reasonable compromise seems to be a 10-file maximum. Sprite sheets can be used to combine images. Given all the factors, we'd recommend the following for standard (non-rich media) ads: 200kb combined total (gzipped) Maximum of 10 files. Any additional must be loaded "politely" (after the parent page finishes loading) Shared CDN resources like GSAP don't count toward these totals. Some have suggested slicing the 200kb standard limit into two parts - a 50kb initial load, and then the rest "politely" loads. However, we advise against this for standard (non-rich media) ads because it unnecessarily complicates the design and production process as well as QA and enforcement. Rich media ads will likely require more files and kb than the limits mentioned above, and those should be polite-loaded. By "rich media", we mean ads that contain video or expand or perform API calls (like feeding the viewer's zip code to a backend script), etc. Update documentation and guidelines It is surprisingly difficult to get answers to some of the most basic questions when preparing a banner ad campaign for even the biggest networks and publishers. What are the file size limits? Which libraries can be used? Do CDN resources count against the total file size? Is there a network-specific CDN link for common libraries? Online docs either have outdated information or none at all related to HTML5. Drop support for IE8 Legacy IE support is not just painful for developers, it's exceedingly expensive for advertisers. Certain effects are outright impossible, so creatives must learn about the IE8 pitfalls and adjust their designs. Developers are forced to rebuild entire portions, implement workarounds and perform extra testing, all to accommodate a tiny fraction of the web audience who probably don't represent the demographic that advertisers are targeting anyway. This was never an issue for Flash, but it's a HUGE issue for HTML5 because it relies on native browser technologies that are absent from older browsers like IE8. Our recommendation is to draw a line in the sand and drop support for IE8 for sure, and potentially even IE9. Consider SVG instead of iframes Displaying ads inside an iframe is nice for security, but it forces ads into a strict rectangular space (ruling out fancy overlays with transparency/mask effects that show the main web page behind) and there's a performance price too. SVG is widely supported and it has some excellent transparency/masking capabilities, plus it can serve as a single container for an entire ad (see Chris Gannon's blog post and video)! Further testing needs to be done to better understand the performance and security implications, but it certainly seems like a worthwhile contender. Create a gallery of sample banners and templates Rather than pouring over specs and instructions and then building something from scratch, most developers prefer to analyze banners that already conform to the standards and use one as a template for their own project. Each network has different API's and ways you must track clicks, etc., so it would be lovely if each one provided a gallery of demos at each standard size. Codepen.io is a great place to host a collection because it's so easy to see (and edit) the HTML, CSS, and JS as well as the result all in one place. Developers can simply click the "fork" button and start producing their own version of that banner immediately in the browser. Codepen even integrates nicely with crossbrowsertesting.com for easy QA. Adjust client expectations As the industry transitions from Flash to HTML5, clients must be made aware of the design, budget, and schedule implications. HTML5 banners take more time to produce and test, therefore they will be more expensive. Plus there are certain effects that were easy in Flash but are virtually impossible in HTML5, so creative expectations need to be adjusted as well. Common GreenSock Questions With the broader discussion out of the way, let's narrow our focus to GreenSock for a moment and address some of the most frequently asked questions: Which networks support GSAP? All networks that we're aware of allow GSAP, and most even exempt its file size from the ads and host it on their CDNs. Google DoubleClick recommends GSAP for complex animations. Here's a breakdown of how some of the major players stack up: Allows GSAP Excludes GSAP from file size calculation* Hosts GSAP on CDN Advertising.com/AOL YES YES YES Google DoubleClick YES YES YES Flashtalking YES YES YES Sizmek YES YES YES Flite YES YES YES Cofactor YES YES YES AdWords YES YES YES *Unless publisher objects which is uncommon TweenMax is too big! Where's TweenNano? Let's face it: TweenMax (the most robust tool in the GSAP suite) is overkill for many banners that are only doing simple fades and movement. Wouldn't it be smart for GreenSock to create a super-small animation engine that's targeted at banners and only has the basic features? In the Flash days, we did exactly that and called it "TweenNano". It weighed about 2kb. On the surface, it sounds like a great idea but there are several reasons we avoided TweenNano in the HTML5 toolset: Caching - this is the biggest factor; loading the JavaScript file is a one-time hit and then the browser caches it, mitigating the entire loading issue on every page thereafter. Realistically, TweenNano must include a subset of TweenLite and CSSPlugin features and weigh at least 8kb; how much longer would it take for the average user to load an extra 25kb for TweenMax? It's not even noticeable (less than one second). So it doesn't seem like a worthwhile tradeoff to rip out all those features just to gain a fraction of a second only the first time it loads, especially for banners where caching and resource sharing could be used so effectively. If networks toss TweenMax.min.js on their CDNs, it effectively becomes "free" (zero load time) very quickly, giving them instant access to all the timeline tools plus a bunch of advanced plugins. Thus it seems smarter to press the full-featured, super-fast TweenMax engine into service rather than a sliced-down TweenNano with limited effects. Performance - GSAP has been engineered with a huge priority on performance which sometimes comes with a file size tradeoff. We could accomplish the same tasks with less code in places, but runtime performance would suffer. We feel strongly that when it comes to animation, it's wiser to pay a small up-front kb tax (only a fraction of a second in most cases) in order to get maximum runtime performance. Animations must look smooth and conserve battery power. Think of it this way: would you rather buy a computer that boots up 2 seconds faster or one that's 30% faster all the time (after it boots)? Flexibility/Creativity - what if you want to animate a non-essential CSS property like boxShadow or slide along a curve or scrub through a timeline? Even if there's just one part of your banner that needs a more advanced feature, it presents a dilemma. Creativity is hampered. Again, the fraction of a second one-time cost difference for TweenMax seems well worth it for the added flexibility and peace of mind. API confusion - years ago, Adobe created a lightweight version of the Flash Player dubbed "Flash Lite" with similar aspirations (bake only the essentials into a lighter weight flavor), but it was a complete failure. One of the problems was that developers couldn't remember which features were available in the regular Flash Player versus Flash Lite. Likewise, TweenNano's feature disparity would create some confusion/frustration. What about creating a tool that lets users select only the features they need, and then it spits out a customized stripped-down version of TweenMax? Again, this sounds appealing, but it would likely lead to worse load times because instead of having one common TweenMax that gets shared and cached, every banner would have its own different (and partially redundant) flavor to load. Ultimately, we're committed to delivering the tools that are needed most, so if the broader industry decides not to leverage shared resources and publishers insist on sticking to all-inclusive aggregate file size totals, we're open to creating TweenNano. Luckily, it looks like there's excellent momentum behind TweenMax getting CDN-ified and exempted from file size limits. In our opinion, that's definitely the smartest approach. What's so special about GSAP? It's beyond the scope of this article to explain all the benefits of using GSAP; see http://greensock.com/why-gsap/ for a summary. If you're still wondering what the big deal is, we'd encourage you to find someone who is proficient with it and ask about their experience. Usually people who take the time to learn it have a "light bulb" moment pretty quickly and never want to go back to using other libraries or CSS. It's difficult to explain to the uninitiated - lists of features don't really do it justice. It's not merely about performance (although that's a biggie) - it's about feeling empowered to animate almost anything you can imagine with minimal code. Do I need a commercial license to use GSAP in banner ads? GreenSock's standard "no charge" license covers usage in banner ads even if you get paid a one-time fee to produce the banners. We fully encourage the use of GSAP in banner ads and beyond. You may want to check out Club GreenSock for some bonus plugins that allow you to easily achieve advanced effects. Is anyone building a GUI for GSAP? A visual tool for building GSAP-based animations is a popular request, and we have been approached by several large and small companies about the possibilities, but there's nothing rock solid to report yet. We hope that companies like Adobe and Google will offer export options from their tools that leverage GSAP as the runtime engine and produce well-formatted, concise code. There's a pretty neat tool called Animachine that's in alpha and can be installed as a Chrome extension. It shows promise, but isn’t entirely stable at this point. There are also several online GSAP-based banner builders: http://html5maker.com/, https://tweenui.com/, and http://www.loxiastudio.com. Where can I get GSAP training? You can have GreenSock come directly to your organization and sit with your team to get them up to speed quickly. We can even convert one of your Flash banners and then teach you how we did it which is an excellent way to learn banner-specific tricks. The Q&A sessions are invaluable. We have limited slots available, though, so contact us as soon as possible to get your event scheduled. There are plenty of other learning resources available: GreenSock's getting started video/article GreenSock's learning resources New GreenSock eBook (published by Noble Desktop) Lynda.com course ihatetomatoes.net course (intermediate/advanced) Noble Desktop class in NYC 02Geek course Egghead.io The GreenSock forums are a fantastic place to not only ask your question(s), but also poke around and see what others are saying. It's one of the best places to learn even if you never ask a question. There are plenty of demos on codepen.io as well. For inspiration, we'd suggest following these people: Chris Gannon Sarah Drasner Petr Tichy Sara Soueidan Diaco.ml Blake Bowen Ico Dimchev UPDATE: The IAB released a draft of its new HTML5 specs and is soliciting public feedback before finalizing the document. The outstanding news is that they agreed with our assessment regarding a 200kb limit for standard ads. The IAB is expected to release an update to its HTML5 Best Practices guide soon which will likely contain a short list of JavaScript libraries that are recommended for exemption from file size calculations. We're confident GSAP will be on that list. #network-support { border-spacing: 1px; border-collapse: separate; background-color: #ccc; width: 830px; line-height: 1.1em; } #network-support thead td { background-color: #333; color: white; } #network-support td { text-align: center; vertical-align: bottom; font-family: Asap, Arial, sans-serif; padding: 10px 14px; background-color: white; } #network-support .network { text-align: left; font-weight: bold; } #network-support .yes { background-image: url(/wp-content/themes/greensock/images/licencing-check.png); } #network-support .yes, #network-support .no { background-color: white; background-repeat: no-repeat; vertical-align: middle; background-position: center center; background-size: 35px 35px; color: transparent; } .disclaimer { font-size: 11px; color: #777; padding: 2px; }
  12. GreenSock

    Animating SVG with GSAP

    Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. When it comes to animation, SVG and GSAP go together like peanut butter and jelly. Chocolate and strawberries. Bacon and...anything. SVG offers the sweet taste of tiny file size plus excellent browser support and the ability to scale graphics infinitely without degradation. They're perfect for building a rich, responsive UI (which includes animation, of course). However, just because every major browser offers excellent support for displaying SVG graphics doesn't mean that animating them is easy or consistent. Each browser has its own quirks and implementations of the SVG spec, causing quite a few challenges for animators. For example, some browsers don't support CSS animations on SVG elements. Some don't recognize CSS transforms (rotation, scale, etc.), and implementation of transform-origin is a mess. Don't worry; GSAP smooths out the rough spots and harmonizes behavior across browsers for you. There are quite a few unique features that GSAP offers specifically for SVG animators. Below is a list of common challenges along with GSAP solutions. This page is intended to be a go-to resource for anyone animating SVG with GSAP. Before moving on, make sure you download the latest GSAP. Challenge: scale, rotate, skew, and move using 2D transforms No problem. 2D transforms work exactly like they do on any other DOM element. gsap.to("#gear", {duration: 1, x: 100, y: 100, scale: 0.5, rotation: 180, skewX: 45}); IE and Opera don't honor CSS transforms at all, so GSAP applies these values via the SVG transform attribute like: <g id="gear" transform="matrix(0.5, 0, 0, 0.5, 100, 0)">...</g> When it comes to animating or even setting 2D transforms in IE, CSS simply is not an option. #gear { /* won't work in IE */ transform: translateX(100px) scale(0.5); } Very few JavaScript libraries take this into account, but GSAP handles this for you behind the scenes so you can get amazing results in IE with no extra hassles. Challenge: set the transformOrigin (the point around which rotation and scaling occur) Another unique GSAP feature: use the same syntax you would with normal DOM elements and get the same behavior. For example, to rotate an SVG <rect> that is 100px tall by 100px wide around its center you can do any of the following: gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50% 50%"}); //percents gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "center center"}); //keywords gsap.to("rect", {duration: 1, rotation: 360, transformOrigin: "50px 50px"}); //pixels The demo below shows complete parity between DOM and SVG when setting transformOrigin to various values. We encourage you to test it in all major browsers and devices. See the Pen SVG + CSS Transform Timeline by GreenSock (@GreenSock) on CodePen. More Details Morph <path> data even if the number (and type) of points is completely different between the start and end shapes! Most other SVG shape morphing tools require that the number of points matches. Morph a <polyline> or <polygon> to a different set of points There's a utility function, MorphSVGPlugin.convertToPath() that can convert primitive shapes like <circle>, <rect>, <ellipse>, <polygon>, <polyline>, and <line> directly into the equivalent <path> that looks identical to the original and is swapped right into the DOM. Optionally define a "shapeIndex" that controls how the points get mapped. This affects what the inbetween state looks like during animation. Instead of passing in raw path data as text, you can simply feed in selector text or an element and the plugin will grab the data it needs from there, making workflow easier. MorphSVGPlugin is a bonus plugin for Club GreenSock members (Shockingly Green and Business Green). Other SVG Gotchas GSAP does a lot to remove the hurdles of animating with SVG, but there are still a few things to keep in mind: The current SVG spec does not account for 3D transforms. Browser support is varied. Best to test thoroughly and have fallbacks in place. There are quite a few browser bugs related to CSS transforms on SVG elements, some of which can interfere with GSAP's ability to animate things properly so we'd strongly recommend only using GSAP to apply transform-related properties like scale, rotation, x, y, etc. In Chrome (at least as of June 2015), getComputedStyle() returns the WRONG transform values on SVG elements. It doesn't recognize any non-identity values. So, for example, if you apply a class to an SVG element and it has transform: scale(0), Chrome will say its computed scale is 1. Doh! The same goes for any transforms - if you rotate or move or whatever in CSS, Chrome reports it as scale:1, rotation:0, translate:0, etc. So when GSAP asks the browser for the current value, it'll get bogus data. In Firefox, if you apply a CSS transform to an SVG element, it overrides any transform that is applied via the transform attribute. So if you inspect the element in Dev Tools, you'll see that GSAP is animating the values perfectly in the SVG's transform attribute, but visually you'll see no changes because the CSS class defines something like transform: scale(0) which takes precedence over the transform attribute. As far as we know, there's no way for GSAP to work around this, so it's best to just avoid defining transforms via CSS and use GSAP directly, like gsap.set(..., {scale: 2, rotation: 30, ...}) Most browsers don't GPU-accelerate SVG elements. GSAP can't change that. SVG is lightweight and resolution-independent, but that also can be costly when it comes to performance because rather than just shoving rasterized pixels around (which GPUs are really good at), browsers have to calculate the geometry/paths on each frame. Flash developers will remember converting vectors to bitmaps using cacheAsBitmap. In Flash Player this led to considerable performance gains. Will be interesting to see if browsers offer developers a similar option. Browser support All SVG features in this article will work in IE9+ (IE8 doesn't support SVG) and all other major desktop and mobile browsers unless otherwise noted. If you find any cross-browser inconsistencies please don't hesitate to let us know in our support forums. Inspiration The SVG Animations collection above is just a small sampling of Chris' work. Be sure to also check out Chris Gannon's full portfolio on CodePen and follow him on Twitter for a steady influx of inspiration. Awesome SVG Resources A Compendium of SVG Information - Chris Coyier Understanding SVG Coordinate Systems and Transformations - Sara Soueidan Weighing SVG Animation Techniques (with Benchmarks) - Sarah Drasner SVG Immersion Podcast - Rob Levin Circulus.svg - Sara Soueidan Making SVGs Responsive with CSS - Sara Soueidan How to Scale SVG - Amelia Bellamy-Royds Transforms on SVG Elements - Ana Tudor Ways to use SVG Sprites in Animation - Sarah Drasner Get Started Quickly with GSAP Below are a few resources that will get you up and running in no time: Getting Started Guide with Video Jump Start Sequence Animations like a Pro (video) GSAP Documentation
  13. Feature lists are nice, but they can get lengthy and they don't always tell the story in a way that's relevant to you as the developer or designer in the trenches, trying to get real work done for real clients. You hear plenty about theoretical benefits of CSS animations or some whiz-bang library that claims to solve various challenges, but then you discover things fall apart in all but the most modern browsers or the API is exceedingly cumbersome or there frustrating "gotchas". You need things to just work. .project-post p { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .project-post h2 { padding-top: 16px; margin-bottom: 10px; } .expPoint, .project-post .expList li { font-size: 1.1em; list-style: none; line-height: normal; margin: 0px 0px 0px 8px; padding: 6px 4px 4px 20px; position:relative; border: 1px solid rgba(204,204,204,0); } .expPoint, .expContent { font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; } .expPoint:hover, .project-post .expList li:hover { background-color:white; border: 1px solid rgb(216,216,216); } .expContent { height: 0px; overflow: hidden; color: #656565; font-size: 0.9em; line-height: 150%; font-weight: normal; margin: 5px 0px 0px 0px; padding-top: 0px; } .toggle { width:6px; height:8px; position:absolute; background-image:url(/_img/toggle_arrow.gif); background-repeat: no-repeat; left: 9px; top: 12px; } .expMore { color: #71b200; text-decoration: underline; font-size:0.8em; } #featureAnimation, #featureBox { background-color:#000; border: 1px solid #333; height: 220px; overflow:hidden; line-height: normal; font-size: 80%; } #featureAnimation { position:relative; visibility:hidden; } #featureBox { position:absolute; } #featureAnimation, #featureBox, #whyGSAP, .featureTextGreen, .featureTextWhite { width: 838px; } #whyGSAP, .featureTextGreen, .featureTextWhite { text-align: center; } #whyGSAP, .featureTextGreen, .featureTextWhite { font-size:50px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; top:0; } .featureTextGreen { color:#91e600; font-weight: bold; } .featureTextWhite { color:white; font-weight:normal; } .star { position: absolute; width: 16px; height: 16px; display: none; } #browserIcons { top:64px; left: 100px; width: 92px; height: 92px; position: absolute; text-align:left; } #browserIcons img { position:absolute; } .featureTextMinor { color:#CCCCCC; font-weight:normal; font-size:20px; position:absolute; font-family: "Lucida Grande", "Lucida Sans Unicode", Helvetica, Arial, Verdana, sans-serif; visibility:hidden; } .dot { position:absolute; background-color: #91e600; } #ctrl_slider { position:absolute; width: 725px; height:10px; left:18px; top:196px; background: rgba(80,80,80,0.3); border:1px solid rgba(102,102,102,0.5); visibility:hidden; } Why GSAP? Performance Compatibility Other tools fall down in older browsers, but GSAP is remarkably compatible. Scale, rotate & move independently (impossible with CSS animations/transitions) XNJYHQLJYQEW CSS, canvas libraries, colors, beziers, etc. Total control pause(), play(), reverse(), or timeScale() any tween or sequence. GSAP The new standard for HTML5 animation replay
  14. GreenSock

    GSAP JS 1.9.0 Released

    New DirectionalRotationPlugin Have you ever tweened rotation to a particular value but wished that you could control which direction it traveled (clockwise or counter-clockwise)? For example, if the current rotation is 170 and you tween to -170, normally that would travel counter-clockwise -340 degrees but what if you prefer rotating 20 degrees clockwise instead? Or maybe you just want it to go in the shortest direction to that new position (20 degrees in this case). This is all possible now with the DirectionalRotationPlugin. Previously, shortRotation was available in CSSPlugin, but there were three shortcomings (pardon the pun): It always went in the shortest direction - it wasn't possible to define a particular direction (clockwise or counter-clockwise). It required using a different property name ("shortRotation" or "shortRotationX" or "shortRotationY") instead of the regular property name ("rotation" or "rotationX" or "rotationY"). It only worked on DOM elements. What if you have a generic object or an EaselJS Shape (or whatever)? The new DirectionalRotationPlugin solves all of these issues. First of all, its functionality is baked into CSSPlugin, so you don't even need to load the DirectionalRotationPlugin if you're only animating DOM elements. The plugin is also included in TweenMax, so there's no need to load a separate plugin there either. Use the new syntax to get the desired behavior - add one of the following suffixes to the value: "_cw" for clockwise, "_ccw" for counter-clockwise, and "_short" to go whichever direction is shortest. Here are some examples: //tweens to the 270 position in a counter-clockwise direction (notice the value is in quotes) TweenMax.to(element, 1, {rotation:"270_ccw"}); //tweens to the -45 position in a clockwise direction TweenMax.to(element, 1, {rotation:"-45_cw"}); //tweens 1.5 radians more than the current rotationX value, and travels in the shortest direction TweenMax.to(element, 1, {rotationX:"+=1.5rad_short"}); If you're tweening a more generic object (anything that's not a DOM element), you can use the DirectionalRotationPlugin. If you pass in a simple value, it will assume you're attempting to tween the target's "rotation" property but you can tween ANY rotational properties of any name by passing in an object with the appropriate properties. Here are some examples: //start with a generic object with various rotation values var obj = {rotation:45, rotationX:0, rotationY:110}; //tweens rotation to 270 in a clockwise direction TweenLite.to(obj, 1, {directionalRotation:"270_cw"}); //tweens rotationX to -45 in a counter-clockwise direction and rotationY to 200 in a clockwise direction: TweenLite.to(obj, 1, {directionalRotation:{rotationX:"-45_ccw", rotationY:"200_cw"}}); As of 1.9.0, shortRotation is deprecated in favor of this new (more flexible and concise) syntax. New AttrPlugin This plugin allows you to tween any numeric attribute of a DOM element. For example, let's say your DOM element looks like this: <rect id="rect" fill="none" x="0" y="0" width="500" height="400"></rect> You could tween the "x", "y", "width", or "height" attributes using AttrPlugin like this: //tuck any attributes you want to tween into an attr:{} object TweenMax.to("#rect", 1, {attr:{x:100, y:50, width:100, height:100}, ease:Linear.easeNone}); You can tween an unlimited number of attributes simultaneously. Just use the associated property name inside the attr:{} object. The AttrPlugin is included inside the TweenMax JS file, so you don't need to load the plugin separately if you're using TweenMax. New TextPlugin This plugin allows you to tween the text content of a DOM element, replacing it one character at a time (or one word at a time if you set the delimiter to " " (a space) or you can even use a custom delimiter). So when the tween is finished, the DOM element's text has been completely replaced. This also means that if you rewind/restart the tween, the text will be reverted to what it was originally. Here is a simple example of replacing the text in yourElement: //replaces yourElement's text with "This is the new text" over the course of 2 seconds TweenMax.to(yourElement, 2, {text:"This is the new text", ease:Linear.easeNone}); If you'd like to use a different delimiter so that instead of replacing character-by-character, it gets replaced word-by-word, just pass an object with configuration properties like this: //replaces word-by-word because the delimiter is " " (a space) TweenMax.to(yourElement, 2, {text:{value:"This is the new text", delimiter:" "}, ease:Linear.easeNone}); Sometimes it's useful to have the new text differentiated visually from the old text, so TextPlugin allows you to assign a css class to the new and/or old content, like this: //wraps the old text in <span class="class1"></span> and the new text in a <span class="class2"></span> TweenLite.to(yourElement, 2, {text:{value:"This is the new text", newClass:"class2", oldClass:"class1"}, ease:Power2.easeIn}); As indicated, defining a newClass and/or oldClass will result in wrapping a <span> tag around the associated text. The TextPlugin is NOT included inside TweenMax, so you'll need to load it separately. Other updates and enhancements in 1.9.0: Added support for hsl() and hsla() colors in CSSPlugin and ColorPropsPlugin Implemented a new (more concise and clear) way to register plugins. Old plugins will still work fine, but most of the new ones in 1.9.0 use the new style of registering which won't work with old versions of TweenLite/TweenMax. Please just make sure all your files are updated. Fixed issue that caused className to be ignored by the autoCSS feature that creates the css:{} wrapper internally. Fixed issue that could cause em not to be translated to px accurately, causing a jump when the start and end units for the tween don't match (like px to em or visa-versa) Fixed backfaceVisibility so that it is properly prefixed when necessary Now setting "float" on a DOM element will work across browsers including Firefox and IE. Worked around issue that caused x/y/z transforms not to work properly if they exceeded 21,474 (or -21,474). Fixed issue that caused values not to be interpreted correctly if a negative number had a relative prefix, like "+=-50px" or "-=-50px" Fixed issue in EaselPlugin that prevented ColorMatrixFilter tweens from working correctly when the starting matrix wasn't an identity matrix Now fromTo() and staggerFromTo() methods have immediateRender set to true by default, just like from() and staggerFrom() always did. This seems like the preferred behavior for most developers, but you can certainly set immediateRender:false on any tween if you prefer that behavior. Now fromTo() and staggerFromTo() tweens that have immediateRender:false will record their pre-tween values (before even implementing the "from" part of the tween) so that if their parent timeline rewinds past the beginning of the tween, it restores values to their originals. Get it now Download the latest version of GSAP using the fancy new download screen, and notice that everything is also available as CDN links as well. The docs have been updated to reflect all these changes. Questions? Swing by the forums to get your questions answered.
  15. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. GSAP's CSSPlugin is now super-charged to handle some slick new CSS3 properties like 3D transforms, boxShadow, textShadow, borderRadius and clip. Plus you don't need to worry about a litany of vendor prefixes. GSAP makes it easy to create next-generation effects today. [Note: the animation below is NOT a video - it's regular DOM elements being animated with GSAP. And yes, the scrubber works!] 3D transforms textShadow boxShadow borderRadius clip JS -moz- -o- -webkit- -ms- -no-more- play These features work in virtually all modern-day browsers (see caniuse.com for details about browser support for each feature). Generally if the browser supports the css property (browser-prefixed or not), you can animate it with GSAP's CSSPlugin. In fact, GSAP even works around several browser bugs and glitches to deliver a whole new level of consistency to your animations. It can't work miracles or, for example, permit fancy 3D transforms in IE8, but it does a bunch of work under the hood to empower these features as consistently as possible. 3D Transforms Browser support: GOOD (Chrome 12, Safari 4, Firefox 10, IE 10, iOS 3.2, Android 3.0) see details GSAP makes it a breeze to create amazing 3D effects. In addition to all the standard 2D transform properties like rotation, scaleX, scaleY, x, and y, you can also tween 3D properties like rotationX, rotationY, rotationZ, z, perspective and transformPerspective. You can even create multiple tweens that animate each property independently in a staggered fashion and/or with different eases (something virtually impossible to do with CSS3 transitions). In order to get the most out of these 3D properties, it's important to understand how perspective and transformPerspective work. They both affect the amount of distortion applied in 3D space. transformPerspective affects only the element that is being animated, making it look as though it has its own distinct vanishing point in its own 3D space. You can choose to give each element a transformPerspective specifically or use CSSPlugin.defaultTransformPerspective to set a default that will be used for all animated elements that don't have one specifically defined. transformPerspective no transformPerspective No visual distortion at all. Impossible to distinguish vanishing point or depth. DOM elements by default have no transformPerspective. transformPerspective:200 The lower the transformPerspective, the more extreme the distortion. transformPerspective:600 With a higher value the 3D effect is less pronounced. play perspective should be applied to the parent of the element(s) being animated - an element's perspective affects all of its children, allowing them to share a common vanishing point. Typically this is the best way to apply realistic perspective to multiple elements (instead of using transformPerspective on each child element). Practically speaking, you'd almost never use BOTH transformPerspective AND perspective. transformPerspective Vs perspective transformPerspective is applied to each box causing each box to have its own vanishing point A single perspective is applied to the parent div of all the boxes causing each box to share the same vanishing point play transformOrigin can add some really interesting effects - think of it like a pivot point around which your transforms happen. By default, it is in the center of the element ("50% 50%"). transformOrigin is a space-delimited string of values in the following order [x-axis y-axis z-axis] (the z-axis value is optional). You can define the values using the keywords "top", "left", "right", or "bottom" or use percentages (bottom right corner would be "100% 100%") or pixels. transformOrigin The negative z-index (-200) set in the transformOrigin properties of the second animation changes the effect drastically. TweenMax.to(box1, 3, {rotationY:360, transformOrigin:"left top"}) TweenMax.to(box2, 3, {rotationY:360, transformOrigin:"left 50% -200"}) play Caveats: Performance can vary greatly between the browsers. Generally Webkit browsers like Chrome and Safari do best by far, and Firefox lags behind but updates are getting pushed out pretty aggressively by everyone so things can change fast. In some browsers, you may notice a slight shift of pixels when an element starts/ends a 3D animation. This has nothing to do with GSAP - it's the browser jumping into 3D mode and working with the GPU. The only known workaround is to make sure you apply some sort of 3D transform from the beginning which you could do in your css like "transform:translateZ(0.1px);" (plus the obligatory vendor-prefixed variations). Font antialiasing can appear to change when there's a 3D element on screen. Again, this is a browser issue and has nothing to do with GSAP. In Webkit browsers, you can [mostly] resolve this by setting -webkit-font-smoothing:antialiased in your css. If a browser doesn't support 3D transforms, they will simply be ignored (no errors are generated). In some versions of Firefox, elements with BOTH a boxShadow AND 3D transforms applied don't always render correctly (again, it's a browser issue). We're not aware of a workaround but we expect Firefox to fix the bug in a future release. IE10 supports 3D transforms, but it does not support transformStyle of "preserve-3d" (see Microsoft's site for details). textShadow Browser support: GOOD (Chrome 22, Safari 5.1, Firefox 15, IE 10, Opera 12.1, iOS 3.2, Android 2.1) see details textShadow takes a space-delimited string consisting of up to 4 values (just like standard css) h-shadow: The horizontal offset of the shadow. Negative numbers are allowed. v-shadow: The vertical offset of the shadow. Negative numbers are allowed. blur: Blur distance (optional). color: Shadow color (optional). Use any color format: #ff000, #f00, red, rgb(255, 0, 0) or rgba(255, 0, 0, 0.5) for control over the opacity of the shadow. TweenMax.to(element, 0.2, { textShadow:"10px 10px 10px rgba(255, 255, 255, 0.5)" }); Move your cursor over each word to see a different textShadow effect. GLOW BLACKOUT GHOST TweenMax.to(glow, 0.2, { textShadow:"2px 2px 15px rgba(145, 233, 0, 1)", color:"#91ff00" }); TweenMax.to(blackout, 0.2, { textShadow:"1px 1px 1px rgba(255, 255, 255, 0.5)", color:"#000" }); TweenMax.to(ghost, 0.2, { textShadow:"0px 0px 15px white", color:"none" // IE10 unfortunately hides the shadow too }); boxShadow Browser support: VERY GOOD (Chrome 22, Safari 5.1, Firefox 15, IE 9, Opera 12.1, iOS 3.2, Android 2.1) see details A nice boxShadow animation can visually lift an element off the screen or add an attention-grabbing glow effect. Repeat and yoyo a TweenMax to give it a pulsing glow easily. boxShadow takes a space-delimited string consisting of up to 5 values in standard css form: h-shadow: The horizontal offset of the shadow. Negative numbers are allowed. v-shadow: The vertical offset of the shadow. Negative numbers are allowed. blur: Blur distance (optional). spread: Expansion amount of the shadow beyond the size of the element (optional). color: Shadow color (optional). Use any standard color format like #ff000, #f00, red, or rgb(255, 0, 0). TweenMax.to(element, 0.5, { boxShadow:"0px 0px 10px 10px rgb(0, 204, 0)" }); Move your cursor over the buttons to see a variety of boxShadow effects. sharp shadow blur shadow black spread orange glow green pulse white blur TweenMax.to(sharpShadow, duration, { boxShadow: "10px 10px", }); TweenMax.to(blurShadow, .3, { boxShadow: "10px 10px 10px", backgroundColor:"black" }); TweenMax.to(blackSpread, .3, { boxShadow: "0px 0px 10px 6px black", backgroundColor:"black" }); TweenMax.to(orangeGlow, .3, { boxShadow: "0px 0px 10px 4px #f60", backgroundColor:"#f60", borderColor:"#f60" }); TweenMax.fromTo(greenPulse, 0.7, { boxShadow: "0px 0px 0px 0px rgba(0,255,0,0.3)" }, { boxShadow: "0px 0px 20px 10px rgba(0,255,0,0.7)", repeat: -1, yoyo: true, ease: Linear.easeNone }); TweenMax.to(bsBox5, 0.5, {backgroundColor:"black"}); TweenMax.to(whiteBlur, .3, { boxShadow: "0px 0px 24px 6px white", backgroundColor:"white", color:"#999" }); borderRadius Browser support: VERY GOOD (Chrome 22, Safari 5.1, Firefox 15, IE 9, Opera 12.1, iOS 3.2, Android 2.1) see details CSSPlugin deftly handles a variety of borderRadius values, animating between them with ease. Specify the radii of all 4 corners in a single string and CSSPlugin will know exactly what to do. Use px, em, % or any unit you want, just like standard css. //applies same value to all 4 corners: TweenMax.to(element, 1, {borderRadius:"25px"}); //unique values for top-left, top-right, bottom-right, bottom-left TweenMax.to(element, 1, {borderRadius:"10px, 4px, 12px, 0px"}); //top-left and bottom-right 10px | top-right and bottom-left 4px TweenMax.to(element, 1, {borderRadius:"10px, 4px"}); The demo below illustrates a variety of ways to animate borderRadius. Sample a variety of borderRadius animations by rolling over each grey shape. TweenMax.to(box, .75, { //all 4 corners borderRadius:"25px" }); TweenMax.to(box, .75, { //all 4 corners borderRadius:"50%" }); TweenMax.to(box, .75, { //top-left and bottom-right | top-right and bottom-left borderRadius:"0px 20px }); TweenMax.to(box, .75, { //top-left | top-right and bottom-left | bottom-right borderRadius:"0px 20px 50px" }); TweenMax.to(box, .75, { //top-left | top-right | bottom-right | bottom-left borderRadius:"0px 20px 50px 50px" }); TweenMax.to(box, .75, { //top-left | top-right | bottom-right | bottom-left borderRadius:"50px 50px 50px 0px" }); clip Browser support: VERY GOOD (Chrome 2, Safari 1.3, Firefox 1, IE 9, Opera 9.2, iOS 3.2, Android 2.1) see details The clip css property controls the clipping region for an absolutely positioned element (that's not a GSAP limitation - that's how it works in plain css too). Any part of an element that would render outside the clipping region will be invisible. This includes the content of the element and its children, backgrounds, borders, outlines, and even any visible scrolling mechanism. You define the rectangle as "rect()" containing a comma-delimited list of four values — top, right, bottom, and left—in that order. Negative length values are allowed. The top and bottom positions are relative to the top border edge of the element’s box. The left and right positions are relative to the left border edge in a left-to-right environment, or to the right border edge in a right-to-left environment. TweenMax.to(element, 0.5, { // rect(top, right, bottom, left) clip:"rect(0px,150px,150px,0px)" }); Move your cursor over the images to see a variety of clip effects. TweenMax.from(img1, 1, {clip:"rect(50px 100px 50px 0px)"}) TweenMax.from(img2, 2, {clip:"rect(100px 0px 100px 0px)"}) TweenMax.from(img3, 2, {clip:"rect(50px 50px 50px 50px)"}) TweenMax.from(img4, 2, {clip:"rect(0px 100px 100px 100px)"}) When doing a from() tween (as demonstrated above) that uses the css clip property the target of the tween must have a clip property applied prior to the tween running. View a simple example or the full demo code. Note: although the sample code on this page uses TweenMax, CSSPlugin works equally well with TweenLite. Just don't forget to load CSSPlugin with TweenLite (it's already included inside TweenMax's js file for convenience). Conclusion There has never been a better time for animation in the browser. Before now, developers had to wrestle with clunky css transitions or css animations which can't accommodate even moderately complex sequences with fine-tuned control over individual properties or deliver solid control over entire sequences, plus they couldn't work around some of the browser bugs (like Safari's major transformOrigin inconsistency or Firefox's randomly disappearing 3D transforms) and they required a bunch of prefixes and redundant code. JavaScript options were very limited as well and none (that we could find) solved some key issues. With GSAP, you can finally get the control and consistency you need and it delivers solid performance as well (much better than jQuery - see the "cage match" for a detailed comparison). Make sure you download a fresh copy of the GSAP JavaScript files from the main GSAP JS page and go have some fun (if you're a Club GreenSock member, you can download it with your bonus plugins from your GreenSock account). If you haven't used GSAP before in JavaScript, check out the Jump Start. Got questions? Drop by the forums and post there.
  16. I have this issue where I'm tweening a solid element and while the tween is animation there's a weird white line on the right bottom of the element. Once the Tween is complete the white border disappears. The weird part is that it's only visible on safari (mobile and desktop). Please see the code pen for simplified example. PLEASE HELP!!!
  17. Hello Again The following works nicely var tl = new TimelineLite(); var $frame1 = document.getElementById('frame1'); var $txt1 = document.getElementById('txt1'); var $txt2 = document.getElementById('txt2'); tl.set($txt2, {opacity:0}) tl.add( TweenLite.to($frame1, 1, {alpha:1}) ); tl.add( TweenLite.to($frame1, 1, {backgroundColor:"#ff6a6a"}) ); tl.add( TweenLite.to($txt1,1,{scaleY:0, ease:Elastic.easeOut},2) ); tl.add( TweenLite.to($txt1,1,{alpha:0, ease:Elastic.easeOut}) ); tl.add( TweenLite.to($txt2, 1, {alpha:1}),"-=2" ); tl.play(); It works: my last timelinelite addition happens with intended overlap. But what if I would like to have the alpha begin to fade out as I shrink the text of the same object. This won't work: tl.add( TweenLite.to($txt1,1,{scaleY:0, ease:Elastic.easeOut},2) ); tl.add( TweenLite.to($txt1,1,{alpha:0, ease:Elastic.easeOut}, "-=2.5") ); I tried with a few different values just to make sure it is not the numbers. Is there a way I can do an overlap in tweening of the same object: should I perhaps default to the old skool delay method here and so not put it as a timelinelite parameter but "bake it in with the TweeLite. Thanks again .S, over coffe
  18. Here is another question How come that I can tween CSS properties directly without using the CSSPlugin. The below works. var $frame1 = document.getElementById('frame1') tl.add( TweenLite.to($frame1, 3, {backgroundColor:"#ff6a6a"}) ); tl.play() Am I missing something obvious here? If so, when should the CSS plugin be used since the above works in any case? Thanks in advance .S
  19. I'm trying to create a rudimentary slideshow prototype that plays html container slides, loading their matching gsap animation definitions - on a temporary timeline on the fly, playing it, and then removing it (hide method, l326). The pen has two slides, when you play forward/backwards, the animation plays as expected - as the same timeline animations/properties are played back/forwards on navigation. But when you press the "jump to 1st" button on the second slide (which disrupts the linearity by playing "in" instead of reverse out) tween values that are not changed from 1 between the two timelines (the blue and red box's scale) remain unchanged (0.65, from the "out" animation). How is this possible? If you look at the above method, the timeline is invalidated, the element properties cleared... how was the 0.65 scale from the "out" animation retained? (sorry for the complex example code, had to chop down a larger code, I hope the above description is clear enough)
  20. i have a little carousel and its not tweening to the full duration. i have the tween time set to '0.5' when you click on the "<" button the first 2 times it works, the 3rd time theres no animation as though the duration is set to '0' same if you click on ">" first 2 times its good, 3rd not tweening. am i setting something up wrong? thanks
  21. Hiya - this is my first question, and I hope it's not too dumb. I stumbled across Greensock while fiddling with Edge Animate. However, I'd like to hand-code some of this stuff. Unfortunately, I have virtually zero experience with Javascript. (I did take a class about then years ago, and I vaguely remember some concepts, but that's about it.) My familiarity is with plain-old HTML & CSS. My goal is to try and reverse an animation. Nothing spectacular. However, I don't even know where to start. I'm sure I can cut & paste and tweak, but I'd like a more solid basis. Am I in the wrong place? Thanks! J.
  22. Is it possible to animate a curved line with GS? I want to draw a green line starting from point A to point B with a bezier curve? visual example:
  23. Im trying to achieve a smooth repetitive up and down "floating" effect on x amount of elements - each element with it's own id. After a little while of "floating" the up and down tweening seems to get sluggish. (my real test uses 5 x 100kb images that has been preloaded before tweening) Im using one function to define the up tweening and another to define the down tweening and then throw each element back and forth these two functions. Any suggestion on how I can achieve the same effect more efficient and perhaps even in some smarter way without the two functions are very welcome! My bet is there some "bottleneck" there and that I can perhaps do some simple re-usable timeline instead? Follow the Codepen to see the concept of it
  24. Hi guys, I have a simple tween that tweens the opacity and scale of an element. It's made up of a number of child divs, some with with background images TweenLite.fromTo(elm, 1, { scale: 0, opacity: 0 }, { delay: delay, scale: 1, opacity: 1, ease: Power4.easeInOut } ); Here's a video showing the problem. https://plus.google.com/photos/117519930315665299724/albums/6016203100500855073/6016203101346895106?pid=6016203101346895106&oid=117519930315665299724&authkey=CNaF7OT_gJGA1QE @0:01 - The above tween is run @0:04 - I run another tween which just returns the scale and opacity to 0 @0:10 - I set the elements display property to none @0:15 - I set the elements display property to block @0:19 - Tween scale and opacity to 0 @0:23 - Tween scale and opacity to 1 So at @0:15 it's rendered correctly. but again @0:23 is not again. I assume this is actually a browser issue, it doesn't think i needs to redraw the element after the scaling. The odd thing is though that if I only ever scale from .5 instead of 0 then there are no rendering issues. TweenLite.fromTo(@elm, 1, { scale: .5, opacity: 0 }, { delay: delay, scale: 1, opacity: 1, ease: Power4.easeInOut } ); (it's all fine on chrome desktop)
  25. Hi Guys, I'm wondering can you give me a little help. I'm using TimelineMax within and for loop and the animations are being messed around... basically it looks like everything is being scarmbled CODE: for(var i:uint = 0; i < attackEnemiesToAnimate.length; i++) { enemyToTrack = attackEnemiesToAnimate[i]; createAnimation(enemyToTrack); if(enemyToTrack.x == stage.stageWidth - 20) { attackEnemiesToAnimate.splice(i,1); this.removeChild(enemyToTrack); enemyToTrack = null; } enemyToTrack = null; } private function createAnimation(e:Enemy):void { var tl:TimelineMax = new TimelineMax(); tl.to(e, 0.5, {x:stage.stageWidth - 100, y:50},1).to(e, 0.5, {x:pirate.x, y:pirate.y},2).to(e, 0.5, {x:-stage.stageWidth - 30, y:-stage.stageHeight - 10}, 3); e = null; tl =null; } Any Suggestions Cheers, John
×