Search the Community

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.

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. Since launching MorphSVGPlugin, we've made a bunch of improvements and exposed several new features. Here are the highlights... The challenge Before we dive into solutions, it helps to understand the tasks that MorphSVGPlugin must perform in order to work its magic: Convert the path data string into pure cubic Beziers Map all of the segments between the start and end shapes (match them up), typically based on size and position If there are more segments in one than the other, fabricate new segments and place them appropriately Subdivide any segments with mis-matching point quantities If a shapeIndex number isn't defined, locate the one that delivers the smoothest interpolation (shortest overall distance that points must travel). This involves looping through all the anchor points and comparing distances. Convert all the data back into a string Isolate the points that need to animate/change and organize a data structure to optimize processing during the tween. That may sound like a lot of work (and it is) but MorphSVGPlugin usually rips through it with blazing speed. However, if you've got a particularly complex path, you'll appreciate the recent improvements and the new advanced options: Performance tip #1: define a shapeIndex MorphSVGPlugin's default shapeIndex:"auto" does a bunch of calculations to reorganize the points so that they match up in a natural way but if you define a numeric shapeIndex (like shapeIndex:5) it skips those calculations. Each segment inside a path needs a shapeIndex, so multiple values are passed in an array like shapeIndex:[5,1,-8,2]. But how would you know what numbers to pass in? The findShapeIndex() tool helps for single-segment paths, what about multi-segment paths? It's a pretty complex thing to provide a GUI for. Typically the default "auto" mode works great but the goal here is to avoid the calculations, so there is a new "log" value that will act just like "auto" but it will also console.log() the shapeIndex value(s). That way, you can run the tween in the browser once and look in your console and see the numbers that "auto" mode would produce. Then it's simply a matter of copying and pasting that value into your tween where "log" was previously. For example: TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", shapeIndex:"log"}}); //logs a value like "shapeIndex:[3]" //now you can grab the value from the console and drop it in... TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", shapeIndex:[3]}}); Notes shapeIndex:"log" was added in MorphSVGPlugin version 0.8.1. A single segment value can be defined as a number or a single-element array, like shapeIndex:3 or shapeIndex:[3] (both produce identical results) Any segments that don't have a shapeIndex defined will always use "auto" by default. For example, if you morph a 5-segment path and use shapeIndex:2, it will use 2 for the first segment and "auto" for the other four. Performance tip #2: precompile The biggest performance improvement comes from precompiling which involves having MorphSVGPlugin run all of its initial calculations listed above and then spit out an array with the transformed strings, logging them to the console where you can copy and paste them back into your tween. That way, when the tween begins it can just grab all the values directly instead of doing expensive calculations. For example: TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", precompile:"log"}}); //logs a value like precompile:["M0,0 C100,200 120,500 300,145 34,245 560,46","M0,0 C200,300 100,400 230,400 100,456 400,300"] //now you can grab the value from the console and drop it in... TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", precompile:["M0,0 C100,200 120,500 300,145 34,245 560,46","M0,0 C200,300 100,400 230,400 100,456 400,300"]}}); As an example, here's a really cool codepen by Dave Rupert before it was precompiled: http://codepen.io/davatron5000/pen/meNOqK/. Notice the very first time you click the toggle button, it may seem to jerk a bit because the entire brain is one path with many segments, and it must get matched up with all the letters and figure out the shapeIndex for each (expensive). By contrast, here's a fork of that pen that has precompile enabled: http://codepen.io/GreenSock/pen/MKevzM. You may noticed that it starts more smoothly. Notes precompile was added in MorphSVGPlugin version 0.8.1. Precompiling only improves the performance of the first (most expensive) render. If your entire morph is janky throughout the tween, it most likely has nothing to do with GSAP; your SVG may be too complex for the browser to render fast enough. In other words, the bottleneck is probably the browser's graphics rendering routines. Unfortunately, there's nothing GSAP can do about that and you'll need to simplify your SVG artwork and/or reduce the size at which it is displayed. The precompiled values are inclusive of shapeIndex adjustments. In other words, shapeIndex gets baked in. In most cases, you probably don't need to precompile; it's intended to be an advanced technique for squeezing every ounce of performance out of a very complex morph. If you alter the original start or end shape/artwork, make sure you precomple again so that the values reflect your changes. Better segment matching In version 0.8.1, there were several improvements made to the algorithm that matches up corresponding segments in the start and end shapes so that things just look more natural. So even without changing any of your code, loading the latest version may instantly make things match up better. map: "size" | "position" | "complexity" If the sub-segments inside your path aren't matching up the way you hoped between the start and end shapes, you can use the map special property to tell MorphSVGPlugin which algorithm to prioritize: "size" (the default) - attempts to match segments based on their overall size. If multiple segments are close in size, it'll use positional data to match them. This mode typically gives the most intuitive morphs. "position" - matches mostly based on position. "complexity" - matches purely based on the quantity of anchor points. This is the fastest algorithm and it can be used to "trick" things to match up by manually adding anchors in your SVG authoring tool so that the pieces that you want matched up contain the same number of anchors (though that's completely optional). TweenMax.to("#id", 1, {morphSVG:{shape:"#otherID", map:"complexity"}}); Notes map is completely optional. Typically the default mode works great. If none of the map modes get the segments to match up the way you want, it's probabaly best to just split your path into multiple paths and morph each one. That way, you get total control. Animate along an SVG path The new MorphSVGPlugin.pathDataToBezier() method converts SVG <path> data into an array of cubic Bezier points that can be fed directly into a BezierPlugin-based tween so that you can essentially use it as a motion guide. Watch the video Demo See the Pen pathDataToBezier() docs official by GreenSock (@GreenSock) on CodePen. Morph back to the original shape anytime If you morph a path into various other shapes, and then you want to morph it back to its original shape, it required saving the original path data as a variable and feeding it back in later. Not anymore. MorphSVGPlugin records the original path data in a "data-original" attribute directly on the element itself, and then if you use that element as the "shape" target, it will automatically grab the data from there. For example: TweenMax.to("#circle", 1, {morphSVG:"#hippo"}); //morphs to hippo TweenMax.to("#circle", 1, {morphSVG:"#camel"}); //morphs to camel TweenMax.to("#circle", 1, {morphSVG:"#circle"}); //morphs back to circle. Conclusion We continue to be amazed by the response to MorphSVGPlugin and the creative ways we see people using it. Hopefully these new features make it even more useful. How do I get MorphSVGPlugin? If you're a "Shockingly Green" or "Business Green" Club GreenSock member, just download the zip from your account dashboard or the download overlay on GSAP-related page on this site. If you haven't signed up for Club GreenSock yet, treat yourself today.

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. In recent months, the whirlwind shift to HTML5 in the banner ad industry has prompted a slew of policy changes. Publishers and networks are scrambling to answer questions from designers who want to build things "properly" (a term whose meaning can vary wildly these days). Growing pains abound. Shortly after we published an article describing the state of affairs and offering recommendations for a path forward, the IAB released a draft of their new HTML5 ad specs which echoed many of those recommendations. For example, the file size limit for standard ads was raised to 200kb. This was cause for much celebration across the industry. But we're not out of the woods yet. There is still a persistent mindset about how we look at kilobytes that's crippling the web. This article aims to challenge the old paradigm and explain why it's so important to re-assess kilobyte costs. Why limit kilobytes? Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. File size limits exist to promote better performance. Period. Does conventional wisdom apply the same way in the HTML5 era? As we modernize our kilobyte-count policies, let's remember what the goal is: performance...or more accurately, better user experience. Not all kilobytes are created equal HTML5 has unique strengths that challenge us to move beyond the simplistic "aggregate total file size" mentality of yesteryear. We need to look at kilobyte cost in a new, more nuanced way. There are four primary factors: Cache status When is 35kb not really 35kb? When it's cached. A cached file has absolutely zero bandwidth cost regardless of its size. It loads immediately. This is particularly relevant in banner ads because there are certain chores common to almost every ad (like animation management tasks) that can be encapsulated and shared among many, many banners. The end user only loads that shared resource once and then it's cached and completely "free" thereafter...for all ads pointing at that file...on all sites. Does it really make sense to penalize ads for using those ubiquitous shared resources even though they're so pervasively cached that they don't typically affect load performance? In the modern world, file size limits should apply to the banner-specific assets that have a direct impact on loading times, not standardized shared resources. Location Kilobytes loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically dispersed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability. Spread 200kb spread across 24 files will take longer to download than 200kb spread across only 4 files. This isn't particularly relevant in the discussion about shared resources (which should be cached very quickly), but is an argument in favor of loading TweenMax rather than the combination of TweenLite, CSSPlugin, EasePack, and TimelineLite even though they collectively use fewer kilobytes. If the industry remains focused solely on aggregate total file size, it pushes designers/developers toward less capable solutions that use fewer kilobytes even though they don't necessarily affect load times and could be replaced by more robust options that allow more creative expression. Performance yield Some kilobytes are cheap in terms of the initial load but expensive for runtime execution. If our goal is better user experience, this factor should weigh heavily into the overall kilobyte cost equation. Would you rather have a banner that loads 200ms faster with janky animation or one that's super-smooth at runtime but takes a fraction of a second longer to load? Are publishers primarily concerned with displaying ads faster initially or ensuring that their site runs smoothly once loaded? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. For example, GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, leverages 3D transform matrices, avoids layout thrashing, organizes things internally to make auto overwriting super fast, etc. - would removing those features for the sake of milliseconds on initial load (and zero savings once it's cached) be a step forward or backward? Incentivizing the wrong things If the IAB and publishers don't embrace a common set of shared resources that get excluded from file size calculations... It creates inefficiencies and redundancies - thousands of ads may each contain their own [duplicate] copy of a library like TweenMax, squandering valuable bandwidth. It penalizes the use of robust, industry-standard libraries in favor of custom JS and micro-libraries that probably aren't nearly as capable, well-tested, cached, compatible, or performant. When something breaks, it will be more difficult for the various ad networks and publishers to troubleshoot and support custom JS and diverse micro-libraries. Lots of APIs to learn (or in the case of custom JS, more advanced expertise would be required). GreenSock would likely need to create a minimalistic version of TweenMax that has a tiny subset of the features. We feel strongly that this is a step backward and explain why here. So ultimately, an "all-inclusive" file size policy could actually hurt load times as well as runtime performance. Yet the primary goal of file size limits is to protect performance. Hm. If the industry rallies behind a few popular, well-maintained and performant libraries, exempting them from file size calculations because of their ubiquity, it would not only deliver a better overall user experience, but also make it easier to create high quality banners. There would be fewer headaches for networks and publishers too. TweenMax (GSAP's largest file) technically weighs around 34kb but those kilobytes are the remarkably inexpensive kind. TweenMax is widely cached, it's on multiple CDNs, it packs various tools into a single file (zero "spread"), and it has an extremely high performance yield because of its many runtime performance optimizations. There are so many ads using it already that it has little or no effect on load times. Should it really cost banner ad designers/developers 34kb against their file size budgets? Is it wise to incentivize cooking up their own custom code for handling animation tasks instead? The good news Every major ad network we’ve contacted understands the value of shared resources and is very GSAP-friendly. In fact, virtually all of them have GSAP on their own CDNs and don't count its file size against ads unless the publisher insists otherwise (which is rare). One notable exception is Adwords, but we have been told they're working on a solution. 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 Google DoubleClick is even pioneering a process that will automatically detect when GSAP is used in an ad and swap in its own CDN link to maximize caching benefits. Pretty cool stuff. Conclusion Let's embrace the unique strengths of HTML5 and modernize the way we count kilobyte costs. Let's support policies that incentivize better performance and user experience rather than a race to the smallest total file size for each individual ad. Caching, CDNs, kilobyte spread, and performance yield should all factor into the way we view kilobytes the HTML5 era. FAQ Isn't it unfair if the IAB only recommends a few popular libraries? What about newer or lesser-known libraries? This is an entirely valid concern. The list should be reviewed regularly and the IAB can assess each library's industry support, performance profile, compatibility, and track record for ongoing updates and bug fixes. New contenders could be submitted for consideration anytime. But remember that the key to realizing the performance benefits is keeping the list short so that caching is focused and pervasive. If there are too many "standardized" libraries, it dilutes caching and defeats the purpose. There's no way that everyone will agree on which libraries should be on the list but if we get hung up on not offending anyone or being afraid to appear biased, we'll miss the opportunity to move the industry forward. The list won't be perfect, but not having a list at all is much worse. What happens when a library gets updated? Wouldn't it need to be re-cached? Yes. And trust me - we want libraries to be updated somewhat regularly to work around new browser inconsistencies, patch library bugs, and implement new features that drive things forward. But these updates wouldn't need to interfere with existing or legacy ads - when a library is updated, a new CDN URL would be generated and new ads could optionally point to that version. Those ads would indeed trigger browsers to cache that new version but this should happen very quickly. Most likely within a matter of days the new version would be pervasively cached across the web. Yes, each end user would pay that kilobyte tax once on the first load and then it would be "free" thereafter. Would GreenSock still recommend this policy if GSAP wasn't included in the short list of exempt libraries? Absolutely. This isn't just about getting GSAP an exemption - this is what we believe is best for the industry overall even if GSAP isn't on the list.

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. The latest version of GSAP delivers some fun new features that open up entirely new animation possibilities. Check out the videos and demos below that show what's so exciting about 1.18.0. Here's a quick summary: New "cycle" property allows you to add rich variations to staggered animations Relative HSL color tweens (affect just the hue, saturation or lightness) Complex string tweening like "1px 5px rgb(255,0,0)" Numerous improvements and bug fixes (see github) New "cycle" property for staggered animations Have you ever wanted to animate a bunch of elements/targets and alternate between certain values (or even randomize them) in a staggered fashion? The new super-flexible "cycle" property does exactly that. Instead of defining a single value (like x:100, rotation:90), you can define an Array of values to cycle through (like cycle:{x:[100,-100], rotation:[30,60,90]}) or even use function-based values (like cycle:{x:function() { return Math.random() * 200; }}). The amount of functionality you can pack into a single line of code is staggering (pun intended). Demo: array-based and function-based "cycle" values See the Pen Basic staggerTo() using cycle by GreenSock (@GreenSock) on CodePen. Advanced "cycle" effects with SplitText See the Pen SplitText with stagger and cycle by GreenSock (@GreenSock) on CodePen. Caveats The cycle property is available only in the staggerTo(), staggerFrom(), and staggerFromTo() methods in TweenMax, TimelineLite and TimelineMax. When using function-based values the function will be passed an argument which represents the index of the current tween. Inside the function body, the scope (this) refers to the target of the current tween (see source of first demo above). Relative HSL color animation Have you ever wanted to tween a color to something a little darker or lighter without having to guess at cryptic hex values? How about tween a hue to 180 degrees around the color wheel? With relative HSL tweening, it's easy. You can now use familiar relative prefixes ("+=" and "-=") directly inside hsl() strings! //30% darker backgroundColor:"hsl(+=0, +=0%, -=30%)" //to grayscale (0% saturation) backgroundColor:"hsl(+=0, 0%, +=0%)" //opposite color (180 degrees around the other side of the color wheel) backgroundColor:"hsl(+=180, +=0%, +=0%)" Relative HSL demo See the Pen Relative HSL color tweening in GSAP 1.18.0 by GreenSock (@GreenSock) on CodePen. Caveats Be careful about doing relative tweens when they could be interrupted. For example, if you have a mouseover that creates tween to +=30% and then a mouseout that does -=30% and then the user rolls over/out/over/out, you'll get odd results because of the nature of relativity. For bullet-proof rollover effects with relative values check out the demo we used in the video: Hover Demo with Relative HSL Values When you tween to a saturation of 0%, that basically loses any kind of hue data - the underlying color/hue of grayscale is non-existent. So then if you try tweening back to a saturation of 80% or something, it'll be red because that's the default zero position of hue. For example, tween a blue <div> to "hsl(+=0, 0%, +=0%)" and then to "hsl(+=0, 80%, +=0%)", it'll end up red instead of blue. That's not a bug - it's just the nature of colors in the browser (they end up in the rgb color space). Tween complex string-based values Complex string-based values containing multiple numbers can be animated without any extra plugins. For example, a value like "10px 20px 50px" can be animated to "4px 13px 200px". GSAP will find each number in the strings (in order), compare them and animate the ones that changed. CSSPlugin already does this for CSS values and it even converts units, but the base engine (TweenLite) can now do basic string tweening. It will even find rgba(...) values and make sure to round them appropriately during animation. This new feature extends to AttrPlugin too which means it can animate the complex strings inside SVG element attributes like the points in a <polygon> or <polyline> or even <path> data (please carefully read the caveats below). See the Pen Complex string-based tweening: simple shape morph by GreenSock (@GreenSock) on CodePen. Caveats This feature is NOT intended to perform complex shape morphing in SVG. It simply animates the numbers inside the strings (in order). Robust shape morphing requires dynamically parsing path data and injecting extra points in certain cases. This new complex string-based tweening lays the groundwork in the core to do a lot of advanced effects in the future, especially via plugins. If you're animating the "d" attribute of a <path> element or the "points" attribute of a <polygon> or <polyline> element, keep in mind that you MUST make sure the number (and type) of points match between the starting and ending values. And since those are attributes, use the AttrPlugin (which is already inside TweenMax). Community Demos City Construction by Sarah Drasner See the Pen City Construction Site by Sarah Drasner (@sdras) on CodePen. GreenSock Cycle by Petr Tichy See the Pen GreenSock - staggerTo with cycle by GreenSock (@GreenSock) on CodePen. Special Thanks This major update is extra special as it contains features that were largely shaped by feature requests and feedback from our community. We really appreciate the strong community that we have in our forums that not only helps each other, but also helps shape the tools themselves. Extra special thanks to Elliot Geno for suggesting cycle and relative HSL tweening, Diaco for being a testing powerhouse, and everyone who voted on the API changes. Now go download GSAP 1.18.0 and make something beautiful.