Blogs

WAAPI-Powered GSAP? Unlikely.

Thu, 19 Oct 2017 05:47:00 +0000

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. Overall support is has gotten pretty good but there are multiple levels to the spec, so some browsers may support only "level 1", for example. 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 the CustomEase page). 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 any sort of objects including canvas library objects, generic objects, WebGL values, 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. 2020 EDIT: Now Brian Birtles is the only one working on WAAPI and he does so on a volunteer basis, so further development of WAAPI has understandably slowed down in recent times.

GSAP 1.20.0 Released

Wed, 28 Jun 2017 16:39:00 +0000

Club GreenSock Updates, Q1 2017

Tue, 17 Jan 2017 19:21:34 +0000

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. Club GreenSock members get a fresh batch of superpowers with updates to SplitText and ScrambleText, plus two brand new customizable eases in this 1st-Quarter 2017 update! It's our way of saying "thanks" to those who support our ongoing efforts. Let's dig right into the upgrades... SplitText SplitText now supports nested tags like , , ,
, etc. This means you can split text with various styling and even links. To make things even cooler, SplitText now supports emoji characters ! SplitText demo See the Pen BzmGba by GreenSock (@GreenSock) on CodePen. "Simply Green" gets ScrambleText We moved ScrambleText into "Simply Green" membership level to deliver even more value. NEW: CustomWiggle and CustomBounce Add wiggle and bounce effects to your GSAP animations with these brand new, highly customizable eases. Even get squash and stretch! CustomWiggle and CustomBounce are now included for anyone with a "Shocking Green" or "Business Green" membership. To learn more visit greensock.com/wiggle-bounce. Thanks We're incredibly grateful to each and every Club GreenSock member, as we simply couldn't do what we do without your ongoing support. It's a privilege to have such a top-notch community around GSAP. Please feel free to plug in even more by participating in the forums to help others or to get your questions answered. It's a fantastic place to learn and be inspired. Enjoy the fresh updates, and happy tweening! [loginwidget]

Introducing CustomWiggle and CustomBounce

Wed, 04 Jan 2017 02:18:16 +0000
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 tried getting a realistic wiggle effect or tweaking just how bouncy an ease is? What about adding squash and stretch to a bounce? These are not easy tasks. Well, until now. Even though CustomEase, lets you create literally any easing effect that you can imagine (bounces, wiggles, elastic effects, whatever) by drawing them, it's difficult to plot a complex wiggle or bounce while making sure all the points are spaced correctly. Wouldn't it be nice if you could just set a few parameters (like number of wiggles or bounciness) and have that complex easing curve created for you? Wish granted. CustomWiggle CustomWiggle extends CustomEase (think of it like a wrapper that creates a CustomEase under the hood based on the variables you pass in), allowing you to not only set the number of wiggles, but also the type of wiggle (there are 5 types; see demo below). Advanced users can even alter the plotting of the wiggle curves along either axis using amplitudeEase and timingEase special properties (see the docs for details). Demo: CustomWiggle Types See the Pen CustomWiggle Demo : resized by GreenSock (@GreenSock) on CodePen. Options wiggles (Integer) - number of oscillations back and forth. Default: 10 type (String) "easeOut" | "easeInOut" | "anticipate" | "uniform" | "random" - the type (or style) of wiggle (see demo above). Default: "easeOut" amplitudeEase (Ease) - provides advanced control over the shape of the amplitude (y-axis in the ease visualizer). You define an ease that controls the amplitude's progress from 1 toward 0 over the course of the tween. Defining an amplitudeEase (or timingEase) will override the "type" (think of the 5 "types" as convenient presets for amplitudeEase and timingEase combinations). See the example codepen to play around and visualize how it works. timingEase (Ease) - provides advanced control over how the waves are plotted over time (x-axis in the ease visualizer). Defining an timingEase (or amplitudeEase) will override the "type" (think of the 5 "types" as convenient presets for amplitudeEase and timingEase combinations). See the example codepen to play around and visualize how it works. How do you control the strength of the wiggle (or how far it goes)? Simply by setting the tween property values themselves. For example, a wiggle to rotation:30 would be stronger than rotation:10. Remember, an ease just controls the ratio of movement toward whatever value you supply for each property in your tween. Sample code //Create a wiggle with 6 oscillations (default type:"easeOut") CustomWiggle.create("myWiggle", {wiggles:6}); //now use it in an ease. "rotation" will wiggle to 30 and back just as much in the opposite direction, ending where it began. TweenMax.to(".class", 2, {rotation:30, ease:"myWiggle"}); //Create a 10-wiggle anticipation ease: CustomWiggle.create("funWiggle", {wiggles:10, type:"anticipate"}); TweenMax.to(".class", 2, {rotation:30, ease:"funWiggle"}); Wiggling isn't just for "rotation"; you can use it for any property. For example, you could create a swarm effect by using just 2 randomized wiggle tweens on "x" and "y", as demonstrated here. CustomBounce GSAP always had the tried-and-true Bounce.easeOut, but there was no way to customize how "bouncy" it was, nor could you get a synchronized squash and stretch effect during the bounce because: The "bounce" ease needs to stick to the ground momentarily at the point of the bounce while the squashing occurs. Bounce.easeOut offers no such customization. There was no way to create the corresponding [synchronized] scaleX/scaleY ease for the squashing/stretching. CustomEase solves this now, but it'd still be very difficult to manually draw that ease with all the points lined up in the right spots to match up with the bounces. With CustomBounce, you can set a few parameters and it'll create BOTH CustomEases for you (one for the bounce, and one [optionally] for the squash/stretch). Again, think of CustomBounce like a wrapper that creates a CustomEase under the hood based on the variables you pass in. Options strength (Number) - a number between 0 and 1 that determines how "bouncy" the ease is, so 0.9 will have a lot more bounces than 0.3. Default: 0.7 endAtStart (Boolean) - if true, the ease will end back where it started, allowing you to get an effect like an object sitting on the ground, leaping into the air, and bouncing back down to a stop. Default: false squash (Number) - controls how long the squash should last (the gap between bounces, when it appears "stuck"). Typically 2 is a good number, but 4 (as an example) would make the squash longer in relation to the rest of the ease. Default: 0 squashID (String) - the ID that should be assigned to the squash ease. The default is whatever the ID of the bounce is plus "-squash" appended to the end. For example, CustomBounce.create("hop", {strength:0.6, squash:2}) would default to a squash ease ID of "hop-squash". How do you get the bounce and the squash/stretch to work together? You'd use two tweens; one for the position ("y"), and the other for the scaleX/scaleY, with both running at the same time: //Create a custom bounce ease: CustomBounce.create("myBounce", {strength:0.6, squash:3, squashID:"myBounce-squash"}); //do the bounce by affecting the "y" property. TweenMax.from(".class", 2, {y:-200, ease:"myBounce"}); //and do the squash/stretch at the same time: TweenMax.to(".class", 2, {scaleX:140, scaleY:60, ease:"myBounce-squash", transformOrigin:"center bottom"}); See the Pen CustomBounce from GreenSock by GreenSock (@GreenSock) on CodePen. Where can I get it? CustomWiggle and CustomBounce are membership benefits of Club GreenSock ("Shockingly Green" and "Business Green" levels). It's our way of saying "thanks" to those who support GreenSock's ongoing efforts. Joining Club GreenSock gets you a bunch of other bonus plugins and tools like MorphSVGPlugin as well, so check out greensock.com/club/ for details and sign up today.

Introducing CustomEase

Fri, 02 Dec 2016 17:48:00 +0000
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. 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 (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 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. 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]

GSAP 1.19.0 Released

Tue, 19 Jul 2016 12:00:00 +0000
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 version 1.19.0 introduces some exciting new features for advanced users as well as conveniences for everyone (even the "greenest" novices). The most noteworthy improvements are summarized below: Function-based values Instead of a number (x:100) or string (width:"300px") or relative value (y:"+=50"), you can now define most values as a function that'll get called once for each target the first time the tween renders, and whatever is returned by that function will be used as the value. This can be very useful for randomizing things or applying conditional logic. See it in action in the demos below. See the Pen BzmGba by GreenSock (@GreenSock) on CodePen. ...and more GSAP 1.19.0 is more ES6-friendly (for example, you can npm install gsap and then import {TweenLite, Elastic, TimelineMax} from "gsap" in your project). Plenty of bug fixes too. See the whole list in the github changelog. DOWNLOAD GSAP TODAY Happy tweening!

The "Why" Behind the GreenSock License

Mon, 01 Feb 2016 21:02:50 +0000
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.

MorphSVGPlugin Performance Update

Tue, 22 Dec 2015 00:35:54 +0000
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 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.

Banner ads: the kilobyte conundrum

Thu, 15 Oct 2015 16:53:00 +0000
Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements including a much smaller file size! 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.

Introducing GSAP 1.18.0

Thu, 10 Sep 2015 00:03:27 +0000
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
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 or or even 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 element or the "points" attribute of a or 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.

Solutions for Banner Ads in the Post-Flash World

Fri, 07 Aug 2015 00:06:50 +0000
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. 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; }

HTML5 Banner Survey: Results

Mon, 22 Jun 2015 15:18:49 +0000
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. See the Pen HTML5 Banners - blog post big by GreenSock (@GreenSock) on CodePen. The results are in...and there is clearly a lot of frustration and confusion out there regarding the urgent shift from Flash to HTML5 in banner ads. Thanks to everyone who participated in the survey. Your thoughtful and rather passionate feedback was immensely helpful. It informed our [rather epic] post summarizing where we're at and what's needed to move the industry forward. Read it now: Solutions for Banner Ads in the Post-Flash World. It contains some amazing news regarding GSAP (specifically TweenMax.min.js) being added to some very popular network CDNs. Here are the survey results: What is the single biggest problem you face when creating HTML5 banners? Honestly adding making it compatible to all networks. Specs differ. Also, translating flash effects to svg similar effects or complex text effects in required file sizes. .ss-text-answer-group{ height:500px; overflow-y:scroll; } .ss-text-answer-container { background-color:#fefefe; padding:16px; margin:4px; line-height:28px; border-radius:8px; } .content h2 { font-size:24px; margin:50px 0 10px 0; } Lack of information. Much of the documentation out there is still related to Flash! Probably where to begin, at all. I.e. specs and implementations. That the ad networks don't support them or require me to use their DUMB IDE. That most of the content providers in Norway do not allow GSAP. I think they are trying to limit over-animating stuff, which may affect sites on mobile devices. Guess this is something they have learned from using Flash. Nowadays you need to be more of a programmer than a flash animator. Single lines of code or timeline need much better javascript understanding to be executed. Designers need to consult programmers much more than they used to do with flash. Also for HTML5 banners there are no standards to follow. Each company builds their own standards and publish what they think the best, most often leading to not be suitable to the websites. Size, dealing with assets. The biggest problem I faced was GreenSock not being supported by DoubleClick, also they files cannot end with .min.js. That being said, banner sizes are also a problem. The company we work with is limiting the sizes to 120 KB. Between images and GreenSock we'll pass that. - initial file size of the html5 file -> polite preloader would be great feature. - component base building: this means one component for accessing DOM elements and changing their properties -> smaller then jquery - component that contains all kinds eventlisteners e.g. addEventlister(MouseEvent.Click, ) - possibility for own event listeners. - vertical alignment of text - font size -> should be possible to embed only certain characters from a font file. Rediculously badly written so-called "templates". Next single biggest problem: Media Agencies (that supply rediculous specs). I can't tell you how many HTML5 banners we've had to build that are supposed to use on(release){ _root.getURL() } stuff. They have no idea what they're doing. Either don;t supply a spec Getting file size specs. Not knowing the standards from one media company to the next. Also I have a hard time ensuring that absolutely EVERYTHING including fonts are loaded before the animation starts. File size. The lack of Standards Animating them, it takes a lot of time to do placement and work through the positioning and timing of the animations.Cross browser compatibility, specifications and file weight lol.Advanced 3D animations/transitions Finding publishers that will accept external markup, CSS, and JavaScript Cross browser compatibility. Webfonts, javascript and frameworks. I cant, and wont learn HTML 5. applying vendor code I would think responsiveness or deciding with canvas or CSS animations A number of things. At the forefront is • X platform comparability, 100k file size limits, & use of custom fonts. Responsiveness and height problems with objects not getting pushed down enough. Also, text staying within the boundaries of the box when responsive.The IAB hasn't released updated standards for banners, so most publishers continue to use previous Flash size limits, ie 35k - 40k. CLARIFICATION - FOR NEXT SET OF ANSWERS: These are answered based on HTML5 banners only. I use canvas & SVG for big sites, but haven't yet for banners because of the filesize limitations. Orchestrating frame-by-frame movements. I don't do it often, but when I need it, I need it. Payload size Lack of publisher standards Lack of specifications. The richmedia providers and publishers don't have specifications or some kink of dos and donts. The lack of an IDE similar to Flash. New tools are falling short (GWD, Edge, hand coding, Hype3, Adcade) The lack of a graphic wysiwyg editor like flash ide Filesize (overall), and the inconsistency between publishers / ad serversThat i don't know how to use GSAP inside Google Web Designer. None. I use greensock and it works great as is. Your tools are great. don't need code size to increase to automate things for newbies. lack of browser consistency. File size is a major issue for me right now when making ads for online campaigns. File size. I can't use GSAP so I had to make my own tweening engine. I used the same API as GSAP just in case I am able switch it out. I hope that's okay. I don't know yet how to get the easy workflow that I have with flash and gsap, without doing it all by hand. Cross browser compatibility the limitations. lack of support. Ad weigths and production time A big, fat question mark in terms of specs. Nobody can tell us what the specs are anymore, or whether they should or shouldn't include assets that are pulled in from a CDN. Knowing what authoring tools we are allowed to use. Most of the functionality we use in our banners, as well as platform considerations can stem from what authoring tool(s) we can use, and many of them are platform locked or not compatible with vendors we need to work with. Lack of a refined flash-like IDE for designers who previously did their animation on the flash timeline The difference in delivering banners, HTML / Google web designer / flash / gif / edge Misunderstandings with account, creative, and tech staff about what HTML5 banners are and how they are deployed. get full domain in the use of css3 rules, and the use of canvas I run into multiple issues when creating HTML5 banner ads. I guess for the biggest one with not enough information online is using custom web fonts to stay within brand standards. I still don't understand the rules/laws that comes with fonts especially when a single ad campaign can have multi million impressions. With that, the same brand produces a new campaign every month. The abhorrent nature of Banners in general. Lack of Visual IDE to speed devloplment, and Filesize size. Filesize the size of animations, all scripts included, should stay under 50ko. It should generate datas for tracking audiance and analytics in one animated and graphic datavisualisation system. I do need to include all social networking links. In a more complete version of a Banner solution, I'd like to control all API of social networking and video hosting systems (facebook, twiter, youtube, vimeo, dailymotion) inside my banner. Banner designers are no developers, so, you need to create your first software to build this with no coding. To keep all assests etc. in one file. Like the swf-file format... Lack of standards, education, file sizes, etc. The lack of visual tools to help the development of animations and specially "3D" effects. Usually creative professionals have less experience with coding and UI tools would help it a lot. No good design tool for animators. After doing banners and sites for a big advertising agency, for the last ten years, we need a good ide that will let animators design based on a visual time line. Usually what happens is all the devs get pulled on to websites and more advance stuff and the banners are left to designer/animator/light front end developers. Changes and production need to be fast. Coding banners makes it not a productive and usually ends up being to expensive way to do advanced banners. File size. filesize weight (especially if i need an animation framework) so I need to use pure CSS for animation It is not flash Text (@font-face vs pngs) & javascript libraries like Greensock. Getting ad servers to host these for free. Flashtalking/Sizmek will. Doubleclick will not always host your files on their CDN without counting against k-weight. Also, gZipped files do not count. But regular compressed files for Doubleclick DCM do. No sure about the other adservers right now. Designers not understanding the limitations of HTML5, in particular the fact that, since HTML5 is rendered by the browser, it does not look the same across all browsers and OS variants. Second, lack of standards in terms of minimum file size. Specs clarity (or lack of) The main problem comes for Standard Ads, not for RichMedia Ads. Creatives are used to work with Flash, and now, with html5, the weight of the Ads is going to be bigger, so this will be the hardest difficulty as Ad Specs are extremely strict, specially with the introduction of RTB and programmatic Ad campaigns A user interface for the banner creation. Generally all banners are created by coding css, javascript and html5. File size. Cross domain script loading. Performance especially mobile device Standards. Browser Compatibility. Portability. The ads don't package well and the size isn't optimized as well. finding where my last animation has happen. Size. Lack of timeline takes some of the animation creativity out of the game. I like using greensock mixed with a timeline to show amazing animations with the power of code. I was told that greensock is too heavy and some places are pushing css file size limitations Knowing what tools I will be able to use and if the file size will be too big, also if Google will have a very low bar and not allow GSAP and other tools (JQuery etc) to be used, so even if I build for one publisher using GSAP, will that banner be rejected by Google or we will have to build dumbed down content just for them. inserting-creating that clickTAG macros in a proper - working way File size limitations. Limited docs including specs. More solid guidelines for asset delivery. There are differences between the major ad servers and the only way to figure them out has been trial and error. The size, mostly is the biggest problem - no matter we're talking about image size or js/css code size. Always optimising the size... The filesize, especially if CDN is not allowed Time for development x2 in comparison to flash. No way to make effects such as stroke, glow, drop shadow. Web fonts are quite buggy IE's lack of good mask support, firefox kerning, figuring out if the ad server is going to count the weight of cdn files, such as TweenMax and google fonts, against our banner weight or not. (DoubleClick Studio - no, DoubleClick Media, yes, Sizmek, yes...) Increased Production (Hand coded animation) Increased QA (cross-browser) file size constraints Preroll often it is not allowed to use external libraries but only use css transitions File size Workflows are more diverse in html5 as there is no one single IDE that works for everyone and every platform. Flash did a good job of combining a timeline with code and took many iterations to get to where it is. Cross browser / device all looking and working the same Old assumptions around Flash banners...this happens at all ends: account people, creatives, project managers, ad networks, ad publishers. Everyone has engrained rules-of-thumb and ideas about banner production based on doing them in a pretty stable environment with Flash over the past 15 years. That's all changed. Doing HTML5 is the not same, the creative possibilities aren't quite as good, and the K-weights routinely come in at 2-3 times larger than Flash, nevermind introducing cross-browser/cross-platform issues. Outdated publisher specs is the most immediate issue. 40K doesn't apply to a HTML5 banner. IAB hasn't released new specs yet. It's a free-for-all. Ad networks and publishers are all over the place as far as specs. Many try to apply old Flash banner specs to HTML5, doesn't work. Others impose weird restrictions like limiting the banner to 10 files. Or allowing 3rd-partly libs that count as K-weight sometimes, but not in other cases, etc. We've also found that some publishers of a rich HTML5 unit doesn't resemble anything we would historically call rich--no animation, no story telling, just a chunk of HTML with some copy, links out to PDFs, a video tag, etc. Animation and design still matter.project size Nothing really. I love making banners with only 10 lines of TweenLite code. It's the best! Only thing i miss sometimes is a stage to click on. Especially when working with masks and gradients. (im not a fan working with Edge or GWD) Getting clear specs from different ad servers - e.g. filesize limits namely:does this include the external assets/apis/polite preloaders Low file size requirements are the biggest problem for us. Generally we have to hit a 100k file size spec. Consistent browser support. Use of filters (drop shadow) on transparent png/svg. Cross browser compatibility... Currently I use Flash as my layout program importing a single sprite sheet which will be used for the HTML5 banner. Assembling the images on stage to marry up to with jpgs as comps in guide layers allows me to see match the layout. Then I can animate away. I use Flash / Actionscript with TweenLite AS to develop my animation and then move my actionscript into a javascript file and use TweenLite JS. IN this way I am repurposing my actionscript as javascript. Of course getting the xy coordinates of my movieclips which contain a rectangular mask and a sprite sheet. is the challenge. I use Flash's Actionscript to HTML5 Canvas which produces a javascript file with all my coordinate information contained. The challenge here is to massage the javscript information into variables that I can paste into my HTML5 Javascript file. It's routine to me now and my trick is to have all movieclips each with the sprite contained with a rectangular mask. The movieclips are all placed at x:0 y:0 and the sprite and mask are repositioned to match the JPG layout images on guide layers. Proper Preloading respecting polite loading 40kb banners The ad delivery networks lack of standards and support and the out-dated filesize limits. Designers still designing with Flash in mind, not realising the limitations of HTML5. It's usually a problem that would require some kind of masking. Simply that we haven't figured out a workflow yet for HTML5 banners. Handling fragmentation and cross browser support. Dev Time is longer than with flash. Inconsistency of programing best practices leading to file bloat that pubs are unwilling to approve file sizes for. Best Practices surrounding JS methods. Make it accessible for designers to develop banner independent. No good tools such creative tools such as Flash interface available yet. Positioning Elements Positioning assets in the banner The ksize limits is a huge problem. Even if they accept higher specs, they forget this is all subjective on concept and on creative dimensions. Most websites still say 100k (40k initial, 60k polite) when it should be 150k initial, 2 megs polite. Lack of a good IDE. Edge is good but heavy, and GWD is not there yet, lost of crazy generated files. Doubleclick and adwords ads have to be done in Google Web Designer, I don't know where to place my GSAP tweens, what is the best practice. For other adservers I need to start from a Flash CC canvas export, again I don't know where to place my cdn calls and my GSAP tweens. A last option is to start from an edge template, and my problem is still the same, what is the best way to use GSAP with edge. Lack of specs from sites and publishers, and lack of understanding with project managers as to what questions need to be answered. Specs. We're given the same specs for HTML5 as for SWFs. When they are not the same. 40kb for files. Not true according to Google, hard to find answers for on other ad networks. Second biggest issue is tracking and getting an answer on how to properly setup clickTag tracking. And the last but not least is what authoring environment is accepted. Google wants us to use Google Web Designer(beta, and doesn't show in IE9), we'd prefer to use Adobe Edge Animate(buggy, but shows in IE9) 1. The lack of a unified specs across ad servers (i.e. DoubleClick, Pointroll, Sizmek, etc.) and publishers in terms of K size limit , CDN usage, etc. There is even a difference how ad servers count k size! Some include CDN js links into their k count, some don't. Each has its own set of rules and developers are often just confused. banner size, authoring tools, custom fonts Doing so much stuff manually * A Banner should mostly be created within an IDE because you've got a story to tell. Telling stories just with a codeview is pretty hard. Some can do it - most not. * Optimizing Process (currently done via grunt script) - Fonts, images, compression Having an advertising network which supports it. First of all, fileweight. Second a playback/play/pauze/speed up/speed down functionality to get more visual control over your animation. Smooth scaling/rendering of images/text. The use of fonts which adds a lot of fileweight and it tenders never the same in all the browsers. animation File sizes. Too often when I'm done breaking out creative assets, web fonts, and lining in SVGs to the units I am left with very little space. Too many publishers only accept ludicrously file sizes so I am left animating with no JS libraries and add CSS animation classes from timed functions. coding the banners to be responsive and weight of banners ridiculous file specifications. Some people still think we are in the web of 15 years ago. So 40Kb is still a common ksize request. Not realistic banner size. I recently was asked to convert flash ads to html5 with the same 40k max. Issues with the Ad Serving companies and their file size limitation and the size of the libraries for GSAP. We need a universal CDN approval so that the libraries don't interfere with the creative. Worked great with Flash and the possibility of only using 4kb but those days are over. amount of files and total filesize Developing to Double Click Studio standards, lack of modern documentation for HTML5, little to no consistent specifications. Making sure everything is loaded. I just filled this out but didn't put my email address. This time I will but the main trouble I've been having is getting web fonts loaded properly on IE10 and 11. Was hoping you could let me know if there's a fail proof way of loading everything before the my timeline lite starts. That publishers have not come forward with specs yet. Industry wide confusion. Lack of consistent specs and standards. k-size files size File size of the unit, and out of date specs determining them. Character animations for rich banners such as the Google Android banners. Blurs, masking etc KB Size cross browser inconsistencies + file size restrictions Speed. With the Flash IDE we can created banner very quickly Clients are still used to flash and can't handle either the new asset types nor the requirement for a bigger file size and external libraries. They still want 40 Kb I. E. the syntax not clear Nobody knows what specs to follow in regards to k weight. Google notified us that they will accept 150k as standard units now, replacing 40k flash units. However, many publishers are not accepting the 150k unit. It would help if the IAB was a little quicker. Also, a big issue is masking animations in html5. It's something I did daily in flash but is very difficult in html5. It would be great if all browsers could agree on a masking standard. Our designers want a timeline. I'm very familiar with Greensock for flash so I think it will be easy to adapt. But some tutorials would be great. Browser compatibility Lack of good tools to build with. responsiveness Different platforms with different specs and then only being able to point out problems after you've provided a finished banner (which you need to adapt) some platforms only support a few assets in a banner which will give you to use sprite sheet systems Surety on exactly what is required. file size smoothness of ads in comparison with Flash Web Fonts also, re-cutting graphics for every banner size File size.. keeping assets small and compact and efficient. consistent look I would say there are 2. 1. Feature parity across browsers. Many features of HTML5 are still not implemented properly, for example CSS masking not working in IE. So often the only way to support enough browsers is to use canvas based systems. 2. File size and outdated specs from publishers. We are still getting requests for 40K ads Finding a solution to allow our non-technical designers to create them as they have in Flash. As a designer/lead front end developer I would prefer to hand code with GSAP, but that wouldn't work for most designers. Had to settle on Google Web Designer as a solution for our agency. Masking Create small enough code (including images) for the small filesizes. The lack of one standardized spec to work against. At least back in the flash world we have the ubiquitous clickTag listener. All these companies are coming out with proprietary builders for HTML5 ads which in my opinion just make things worse. Remembering where my last animation was within this imaginary timeline. Big file size Custom fonts are not crossbrowser Adobe edge is completely buggy and not user friendly to work with. PNG optimalisation Lack of tools. Many publications are unclear if you can use anything besides Google Web Designer or Adobe Edge if at all. masking and brand fonts Performance (time to load, time to parse, executional speed), particularly on mobile Complexity...no IDE like Flash, multiple documents, code to edit (HTML, .js). File size. 100k is norm but with CSS support, doubleclick enabler, etc files can easily be 140-180k, which sometimes requires special permission from the publisher and requires polite load. Media agencies being able to supply specs before build There are no clear standards of specification sheets from many publishers / media agencies. They are not educated or prepared for the shift to HTML5. Consistency across platforms, and replaying the entire animation. File size is a huge problem too (pun intended). Getting publisher specifications that are relevant Browser inconsistencies even in up-to-date browsers. Keeping the overall filesize low. Meeting Specs, File Size lack of across the board specs from ad networks and vendors regarding html5 banners and the k weight when dealing with additional JS libraries. File size to include the runtime or GSAP, Sprite Sheets, and just general specs of the publishers What should GreenSock do to help solve the problem(s) you face when creating HTML5 ads? A cross browser masking solution. Custom build of framework that only includes functions that are explicitly required. Provide some templates and examples. It's surprisingly hard to find accurate info on provider specs, etc. Provide minimal banner-only GSAP JS library, perhaps. File size is a killer. I wish there was a Flash-like or GWD-like software UI for GSAP for non-devs. Deliver a tiny tween engine! Invent an alternative to masking (perhaps you have already and I am ignorant of it) A tool that helps easily calculate the file-size of the banner would be great. Maybe something that shows a tally of the k-weight of the Greensock assets we're using, at the very least Just maked all animation work in all browsers. Maybe present an additinal package (much like tweenNano) targeting HTML5-advertising, and being more specific towards content providers to let them know that this is not going to affect their site. I'd be happy to help bring such information to the largest news providers in my country. Don't know, but it would be great to have a platform like flash for all HTML animations. now its ( SGV / Javascript / CSS etc ) Make the library as small as possible. Keep doing what you're doing. Documentation is great. The TimeLineLite tutorial was great too. I never used it in FLash, but find it more valuable for HTML banners. Keep file size light. It would be nice to have a very small js, like TweenNano in flash. Designed for the use in Banners. With only the very basic of functionality. The Goal would be to keep the Ads under 80KB tweennano, modularized custom build (e.g. let me choose single ease equations) One code, works everywhere... Hi, I've been a huge fan of GS for years! CDN hosting is a great idea, but some kind of Timeline Nano product would help us replay the entire ad. I would love a GSAP video control too! Create an gsap authoring tool (better then Adobe Edge) Development tool similar to Flash, where you can combine frame-at-a-time animation with vector animation. Also allow things like path-following. Looks like they are the answer! Sample setup files would be helpful as an example as to which banner structures are likely to get accepted. - the current components should be even more customisable since they are still too general. THis would save file size for the js. - polit preloader container for initial deployment. - components for carousel, sliders - imagescaling e.g. exact fit, centering etc. Nothing. Working with all the major publishers and networks (Double Click, Sizmek, etc) to get GSAP accepted as a CDN download. With official guidelines to state that it does not count towards file size. Not having to ask the same question over and over to each individual publisher and network would save a lot of stress. It would be great if you could motivate Google/Doubleclick to integrate Greensock into Google Web Designer. Also to have them upload the Greensock library to their server so it won't count against the total file size of the zip. front-end development tool Dont know. I don't know any solution that can help me to animate under 50ko including 3D properties, svg, font animation. Educate designers about the limitations of HTML5. Propose standards for file size(s). not sure. Not applicable It should convert all the text to transparent .png characters, and replace the HTML text with these. But i know it isn't a Greensock task to do. More likely a function of a desktop IDE. Greensock should make a canvas IDE for making layouts and hide all the unnecessary programming/typing tasks. Could you guys provide an extremely simplified nano version for html5? Just to have simple tweens, no cross-browsing features (at least we don't have to deal with IE9 or lower now). Create more light/extremely optimized typical components like text scrolls, slides, etc. piece of software to actually make them, a builder that works way better than google, tumult hype, or that smithmicro software. I don't know if GSAP can help more than it does right now. Of course is the best animation library I have worked with, but right now we are in a "panic mode" trying to figure out what is the best approach on creating a banner. Custom templates, tutorials or do's and dont's could be of great help but this is more on the publishers side as the techniques they use for tracking are way different. What would be great for you guys and the rest of the developers creating ads; work closely with Google/Double Click to have the animation libraries and all your Greensock goodies on their servers or baked-in in some other way. Means we aren't requesting from your CDN every time. And also develop some specifications alongside Double Click (and other Ad Networks) to bring some consistency and understanding between us all. From the forums it seems like a knee-jerk approach currently, everyone coming up with their own way of doing things which will cause mass confusion as all Flash developers move over to HTML5. Best of luck with it all! ? Maybe have a page for clients especially for this topic. Then they'll be convinced "ah okay, this is the right way to do it" Be able to use Greensock (HTML5) in Flash the same way one could implement the GS AS3 code. Not sure. Create a plugin that allows us to publish files that will be usable across all networks? An app that let's us know if our ad is in compliance? If not, where does it fail? Nothing I can think of GSAP has made it possible for me. I was lucky to get a year long campaign with a polite load setup so filesize wasn't an issue and I can use TimelineMax, Jquery and retina quality images within that spec. I don't have a problem with writing i code to use greensock in html banners, but banners in flash used timeline because images and everything gets packages into to one nice file, so all you have to do is give somebody a .swf file at you're done. html isn't really good ad embedding, you can ofcourse include javascript and css in the html file but fonts and images still causes grief. Particularly since you can jpg compress a png images and so retain the alpha channel and so images takes up a lot more space than before. most companies have a file size limit on a banner around 50kb, include any font or js library and you're over the limit. A short how-to like this one, thatI've found http://greensock.com/forums-support-files/createJS-demo.mp4 would be very helpful. You already do a very good job...but minimising size and loading times will always be the priority with banners...increasingly I also get asked for mobile platform compatibility...I.e good performance on pages that already have a bunch of code...a lot of it not optician,owed for mobile to boot. roll me a joint? WYSWIG layout tool or similar Create an IDE Greensock should build an ide interface with a timeline for animators to be able to do what they do best. Animate. The hidden backend can be powered by greensock. There is a huge gab with banners not being able to use flash. The program ide flash, not just swf format. Adobe hasn't gotten the exporting to html5 down right yet so I think greensock could be the one to solve the problem. some sort of export function, that exports the tweening in a single css and js file with no external references Have talks with some of the big ad networks to develop a >standard<, easy-to-package advertising format. Push for Greensock CDN to be accepted as standard and not count towards file size. hahhahaa, good question? With the amount of variables it seems like an overwhelmingly daunting task. TweenNano js Love it as it is, other than the file size restriction. Do some joint effort with Google Double Click and then all the other Ad Serving companies will have to follow suit. Is there a way you could have a window loaded type function that would ensure everything gets loaded before animation begins? Make it more like Flash Performance especially mobile device help make sprite sheets to combat That's a hard one, maybe if they could set up a working 300x250 example that can be downloaded, including all header info, links to .js files, even a button with the click tag code included, so we/developers can get a good idea of how to set up the smallest file possible. One thing I find frustrating with code pen is that the header info is not visible in the HTML side. Perhaps adding some of the awesome filters like tint and blur (if that's even possible with HTML/CSS) TweenNano for HTML? Greensock is already helping my transition from Flash banners to HTML banners immensely! Thanks to TweenLite, animating HTML banners is no problem. Lean on the IAB to push for standards. And more specifically lobby to make GSAP a standard library and get penalized for using it against file size. Do the same thing you did when we all used Flash. Show examples of how to use greensock with at least one of the animation tools out there. Showing how to use greensock with codepen is pretty useless for me. I think that we should team up with the IAB to define one main spec for everyone to work against. Make pulling the code from a CDN a standard and allow it not to be considered part of the overall file size. There needs to be a discussion of how to handle fonts as well. Either increased file size allotment for fonts or CDN allowance. We had some SSL issues the other day, that needs clarification. Backwards browser compatibility get GSAP to be available as a CDN link rather than having to be included in the ad source. TweenNano for GSAP 70-100kb is too big for an animation library. We made our own as a quick fix. https://github.com/Super-natural/superTween Have a banner ad FAQ page that has links to major ad server site specs. the timeline is wonderful for scenarisation of animations Just keep doing what you're doing. Creating animations standard That you can modify as you nerf. We could actually use a JS equivalent of LoaderMax! That way we would never ever have to fall back to easeljs' LoadQueue. (Your AS3 videoloader was ridiculously good. A JS equivalent would be awesome) How about building a cross-iframe comms tunnel so building synced ads would be a breeze? :) You have Tweenmax and Tweenlite but what you don't have that Flash did is TweenNano. I've seen (worse) tweeners that were only 6kb. Something closer to this would be fantastic. sizmek have an arrangement with all publishers to exclude gasp libraries from the file sizes, using versions hosted on Sizmek servers. A similar agreement with DoubleClick would be useful. We had once talked internally about building a visual timeline tool similar to Flash that used Green sock, and giving it out for free with your blessing. Most interactive animators I know would cry with joy if you made that program/tool. At first it's all about simple animations (slide in, fade in etc) and same time keeping the kbytes low. SVG is a big thing considering how much vectors were used in flash banners. But sadly SVG is not as smart as Flash what comes to compressing vectors. So SVG usability compared to Flash is one big challenge. I think you are helping incredibly. I have only recently switched over from flash and my past with greensock has meant the shift was very easy. I would have liked to much earlier but demand for flash meant it wasn't possible within my agency. Offer a better tool / user interface for banner creation Lightweight library develop a super minimal, move here-move there, fade-in fade-out and timer functionality, that is less than 10kb Even the TweenLite plus the Easing pack (the most minimal setup as per my understanding) are around 31KB minified. If a banner is around 40-to 80KB this eats a lot of it's size. If GSAP can be optimized even more for banners (e.g. like a separate, smaller library) this shall be great. I think the size is the most crucial issue here. A 'nano' version of Timeline working with Tweenlite create a greesock "masker" plugin I'd love a FAQ dealing with the most asked questions. provide sample code or more tutorial (preferable video format) for every single API First your work is already a big help. A flash like GUI to build banners would be Nice. I don't know with respect to the above - I think there needs to be clear standards across the industry Perhaps GreenSock could have a smaller simplified version just for banners. Personally I've found TimelineMax to be the perfect option for animated banners so if that could be extracted into a library only for banners and adjusted to work with DoubleClick then we'd live in a perfect world. -Help get better banner specs established. We've internally settled on 100KB for a standard unit, not including 3rd-party JS libs -Make working with sprite sheets easy. DoubleClick has a 10-file limit for an HTML5 banner, necessitating sprite sheets for many projects -Get integrated into Flash. Our most viable option right now is the Flash Canvas workflow, which uses CreateJS. Mostly because designers can animate using a familiar Flash workflow. Everyone wants to use GSAP instead of CreateJS's tweening engine, but we can't do both. And just using GSAP means we lose timeline animations. -Get official support from Ad Networks so that we can use GSAP without penalty to K-weights Perhaps provide an online animation interface, sort of like you had for flash, the explorer I think you called it. It't helping a lot already. Well providing TweenLite AS and TweenLite JS allows me to repurpose my actionscript as javascript. That's huge!! Getting the coordinates of mask and sprite sheet positioning is the challenge. I use Flash's HTML5 Canvas conversion to get that data in raw form. I then massage it into meaningful variables as I have to forego the Canvas elements as banners servers and publishers don't want to use the Canvas at this time. Tutorials and working Examples would be nice, like the old Snorkl.tv stuff....or even CodePen based....complete working banner ads. * Simple but powerfull IDE * Support optimizing process Create a simple template/tutorial for each: - Google Web Designer - Adobe EDGE - Flash CC Canvas export user friendly tools Talk to google adwords and other large ad networks. work with ad networks and servers to develop an industry standard that does not rely on a specific content creation platform (like google web designer) Nothing really. Maybe make a special lightweight TweenBanner.js or something that contains the basic animations and TimelineLite. But maybe that's overkill and unnessecary. Simply that we haven't figured out a workflow yet for HTML5 banners. Keep up the good work! You've made these possible! I think doing what you are doing is working! Keep improving technology to make GS a standard library. 1. Create a tweenNano version of GsaP for HTML5 animation specifically for banner usage. A flexible library where you can disable functions like lets say you just want to use x and y position tweens and disable scaling or rotation related functions among other things since you won't need them for that particular banner. Create a tweennano for html. a playback/play/pauze/speed up/speed down functionality. Check whatever you can do for smoother Animation and the usage of fonts. Easily intergratably technologies and avoid elements not broadly and consistently supported. Clients expect ads to work consistently regardless of the technology used and struggle when things look different in the wild from what we provide as preview links. Not much GreenSock can do about it. More tutorials on svgs from 0 to expert. 3d transforms etc. More corporate style tutorials, buttons with masked glints effects, more text animations with corporate feeling. http://www.bannertouch.com/flash/allied/ (Check text effect on box left) Stuff that components like flasheff2 used to do for text and images. Help with those things that are easy with a wysiwyg editor, like set pivot poínters easy, setting masks, complex masks, and to have many deep dimensions as with movieclips in flash. Make your libraries as small and lightweight as possible. Provide more documentation for using TweenLite with canvas (I had a hard time figuring out how to tween alpha with canvas). Perhaps make GSAP even more modular. It's tough, it's pretty great already. It would be great to have GSAP not included in the overall file weight and be seen as the industry standard for animation in the browser. Push for standards and, importantly, for CDN delivered JS files not to be included in the overall file-size restrictions per banner. size A unified development platform that bridged all the disparate rich media and ad serving platforms running on greensock and universal standardization of specs for ads. Improved workflow in Edge Animate (more of an Adobe issue). make an HTML5 TweenLite version with a max filesize of 4~7 kb for banners with a max size of 40/50kb Build a banner making platform! Yay! Or perhaps a custom export from Flash? You already have helped solve the problem- TimelineLite is the best tool for animating html5 banners! The other invaluable tool in my quiver is my favorite png compressor: pngyu, coupled with ImageOptim. Without these png compresses, there's no way I'd be able to get close to the file size spec limits. Document samples that will pass the Rich Media Vendors specs and QA. the above - Your CDN should be robust and stable as millions of requests will be launched to load your library. - Preloads are also important, specially for RichMedia Ads. - Also, for Mobile Ads, you should have a "mini" library to load as many resources as possible. - Any help you can give to creative teams is good. Take into account that they have to implement also different technologies for AdServing (clickTag, tracking, etc) Tweennano library which just covers the absolute basics - element selections, fades, rotates, css transforms. get everyone on the same page and push advertisers for more kb I think GreenSock has done an excellent job with the code. Problem is that I haven't used GreenSock for banners. Will try to do more banner making with GreenSock Is there support for making canvas easier? Haven't looked at new SVG support yet but I find outputting image files for things like flat colored blocks faster, easier than writing code, but could increase k size. Does GSAP integrate with Adobe Edge? I don't know It helps with creating solid cross browser animations. Greensock is pretty awesome, so just keep being awesome! create templates It would be great to have a TweenNano that would allow a very small footprint. One of the biggest differences between Flash & HTML is that Flash includes masked layers and animatable vectors. I can export from Flash an animated vector however it packages a CreateJS which makes a simple animated vector over 50k at the very least. One publisher gave me 100k as my limit, but I just did a ton of banners where the limit was only 35k. Latch into Flash CC 2015 so it can automatically use your library as part of the Create JS framework. I've found that we recently push the latest 2 version releases for browsers, so using flash to html canvas works perfect everytime. Host on a CDN that does not use cookies on script calls. Cloudflare sets cookies which raises flags with publishers luke Google Display Network. Further lighten JS libraries... Does TweenNano exist for JS? provide stable glow, stroke, drop shadow effects and a way to animate it A design environment/toolset instead of coding I'm not sure at the moment, but since HTML5 ads are fairly new, there isn't a whole lot of sources available to answer common problems. You guys need to create a new version just for banners, that has the power of timeline light, tweenlite, ease pack, and css pack combined but lower in ksize. Or fight to get into a cdn and have the traffic networks not account for it as part of the specs for each banner. Also an IDE that is solely green sock is a big opportunity. You guys have the best animation engine out there. There is currently no good way to graphically animate. GWD is not there yet, and Celtra is too expensive. Lots of people are looking up to you guys to figure out the way out of this mess. Also we need a better image and code compression tools that are simple and drag and drop. Also i would love to use the loader manager that you guys create for flash to be use to load css, js, video, etc etc. Since we are all making a bit of a transition it's a bit tough to pinpoint. Even recommended file set ups for banners created from scratch would be a great starting point. For animation, I feel its already doing this. Things like masking, filters, and shader support would be ideal if it were supported. I think integrating in some way with a tool already developed for this end would be a great solution. I've seen some tutorials to use Edge with Greensock and seen some projects like TweenUI and Animachine but none are production ready or a "steady" solution, actually a workaround. I don't know if there is much you can do about the first but for the second I think creating a tweennano level engine would help, or perhaps allowing people to sub select only the parts of the CSS plugin they want to use. All the way down to selecting individual CSS properties that would be tweenable and generate a custom build. More pie in the sky, remaking your liquid stage system in JS and creating a full timeline based animation IDE would be big helps. be as always, an awesome option, maybe more turorial, or examples in codepen Preloading, more canvas related features, effects. Maybe some replacement for CreateJs. Compressing, maybe packaging? Compile the whole thing in one big file like swiffy does (but smarter ;-)? Size and portability Crossbrowser animation - one file format. Possibly get greensock to a lower k-weight. I know might be really hard. Maybe there would be trade-offs. Maybe reducing the weight of the GSAP libraries Like a company I doubt you should-could do anything abouy it, since this part of the job- in my opinion- isn’t your area and your part of the job at all (!!!) but as a "FOR BREAKFAST EATING"AS2-AS3-JS-HTML4-5,CSS-CSS3, GSAP(sry if I’m missing smtng)-working professionals with HARDCORE experience in programming different languages you could send me an IM or e-mail to nkoncar@gmail.com or simply make a thread about that (explanation with example) and doing that making me litterally your slave, saving my life and job….oh guys wrong place for crying, but I am…crying out loud Have components ready, such as youtube, video, social icons, etc that can be redesigned so I can concentrate more on the flow of the animations and how it feels. A tutorial on how to use GSAP on GWD. Break apart your twenlite tween max etc into smaller js's so that I can use only what i need to use and not all of the eases, all of the lite, max functionality. Just what i need. a lot just like tweenNano Develop a "Tween Nano" class that is upgradeable with external JS for animation an so on. This will be a difficult fast because e.g. Google will probably try to promote their own products on the doubleclick platform, but a standardized asset manager with solid svg support would be nice. Maybe integrate production tools like texturepacker a more robust debugging system effect make a TweenTiny fdfd Doing a version of GSAP that's less than 3k minified and gzipped. A good go-to tutorial would be good, or a template. Find ways to reduce the amount of code you need to write. it would be nice to have a tool with drag and drop, play, stop, reverse play, and timeline scrubbing functionality Not sure What do you think about the current HTML5 desktop animation tools? Most of them are ok for creating websites or big animations, but none are well suited towards ad production. Everything has to be so tight for banner ads, you can't have any garbage code. Flash 4! A good IDE for visually laying-out elements is lacking and the code they all produce is bloated. The lack of a wysiwyg graphic interfaces like flash. GWD is maybe the best, but is not yet a solid tool. Still very basic Adds a lot of bloat to the code. A set standard for HTML5 code. Once you're used to use GSAP timeline isn't a real must anymore but wysiwyg placement of elements is crucial. Edge is way to heavy and slow to use, flash canvas can't be used in doubleclick, GoogleWD is lighter, lacks maybe some webfont options or spritesheet generation but feels the best option now. I think that nobody was really ready for this rapid of a change so everybody is scrambling to try to come up with something that might work. I think the best overall HTML Banner Creator right now is Google Web Designer, however it has a lot of shortcomings and bugs that doesn't make it an ideal development environment. They suck. I use Adobe Brackets because it is stripped down with no frills -but still not perfect. It has some plugins to use but I can control the code line by line. I use to use DreamWeaver but found it would add all sorts of junk in my code. Somehow, built in It would be nice to easily work on PHP projects. None of these tools do a good job of that, especially when working on packaged projects like Wordpress or Opencart. Flash is the only one that actually "works" and it's got tons of better offerings then the other 2 major ones. The only advantage GWD has is the Enabler component integration and Maps, other than that, you can use Flash to still output the HTML and then have GWD layout the Enabler component framework for you to load the ad into lol. Adobe Edge Animate is just a waste of time if you already know flash and understand and use all the new features which a lot are better than Edge. Usability is very bad. A handy tool at the moment is Adobe Edge. But its definitely not the best The problem in most cases, is that we prefer to have proper control over the output. Edge output is bloated. But, the tool is also pretty powerful. There are some animations that can only be properly created in Edge. Exporting spritsheet animations to Edge is also handy. Edge js API is kind of vague. Google Webdesigner is so-so. It always uses 3D transforms (not broadly supported) and it doesn't cleanup well after itself (unused/removed keyframe animation definitions remain in the code!). It's also devious to add custom javascript code. Sublime Text is a clear winner, as it codes rediculously fast. We have built our own workflow (that utilizes GSAP!) and buildscripts to create banners fast. They add too bloat to file size, I generally end up making all my units in PHP Storm so I can control the file size. I'd also like something which generates web fonts on the fly and isolates only the characters I use in the creative to keep file sizes down. Right now I currently do this in Font Forge which just feels antiquated. Editable code post-compile. Google Web Developer gives most readable output. Edge is best IDE with most options updatability. I'm not impressed with any of the tools from a file size stand point. They're all great for animation, but then mountains of code are generated. The must haves are code optimization and masking. not applicable Edge Animate is not a full product (many bugs, poor properties), but it's known by every agencies. So, I need to use it. Hype seems to be a better solution, but no one knows it. I need a solution that propose a French interface. I use Sublime Text + a grunt workflow. They are far not finished, and they can't handle the font problem. Edge Animate is not able to export canvas based ads. Flash can't use system fonts like before with .swf format. I don't use any. I prefer writing out the TimelineMax code; however if GreenSock supported their own animation tool I'd be more inclined to use it. I think that they are getting better but GreenSock has the edge. It's just weight that I'm mostly concerned with Visualization windows They are too simple and hard to control and make update. They create more problems than going from scratch and are confusing, Edge is cool and fast but heavy on the export. We need something that car work with a regular website setup. SVG integration when editing complex elements with groups are not too good. Usually i code my animations but i prefer Adoge Edge I find them all to be awful (Flash is still winning, but createJS is ~35k). I am the director of a motion department for interactive animators. We have all kinds of animators, even some traditional. Flash/Canvas is currently the only tool that allows them to use their skill set completely. We have all learned handcoding because of the lack of good animation tools. Masking is a must have (and a larger issue). Complex nesting is a must have. A true timeline is a must have (not sequencing). Fine controls are a must have (frame by frame). All export is too bulky, multiple formats are very time consuming to setup. I must say using flash with js export is exciting but... Because of the file size unusable for doubleclick I try to avoid them all. i think google is wonky and hard to work with and the speed of the app sucks. edge animate is great, easy to use and uses commonly understood paradigms. the issue is the additional js library it makes you use. animation IDE tool easiest way to focus on visual art than the code Nearly good enough. Animating svgs like outlines and easily separating vector parts They are bad awful. Hand coding only. As a Flash Professional user, I have switched to Google Web Designer as I am making banners for DCM Studio. I have checked Adobe Edge Animate and Flash for such purpose, but Google Web Designer is very well thought off and it is easy to use it for banner creation or HTML5 animations. It has all basic tools, and while it's not perfect it is quite a good tool. Simple and effective, this is the key. Adobe Edge animate or Flash are not bad at all, just they have too much unnecessary tools and in addition these are not too easy to use with DoubleClick an example. Good banner tool shall offer compatible versions for all of the Publisher Platforms. Optimizing output in a way you can still edit file size is too big Lacking, I need to find a good tool for this that works with green sock. I think that is my biggest problem, just seeing the question above, I now have to check out Google Web Designer, as my company has not upgraded to Adobe CC for Edge Animate and Flash. I like hype more, but my workplace for example has pc's. Hype only works on mac's, so I use Edge. I use adobe edge a lot, it is a good interactive webtool, but it support for responsive design is not great... looking for improvement for that no one is flexible, so no winners except notepad for now They are subpar to what Flash is. Working for large agencies with high deliverables and tight deadlines the shift has really been to scripting animation over the years. Moving to javascript animation has been smooth using greensock. I've tried working with GWD and Edge- too bulky and slow. If Adobe can somehow make Flash output small / readable HTML5 that would be ideal for a lot of people. It probably needs to be rebuilt from the ground up or it would have been done already though. Stability. Edge corrupts animations easily. Google Web Designer lacks advanced animation and doesn't play at all in older browsers. I've tried using GWD but couldn't get the hang of it. I use GSAP for all my animation, so the only benefit I see with these tools is being able to quickly layout my DOM elements. When using GSAP alone, I have to plot my X and Y values manually, which can become tedious after a while. I did look into Adobe Edge very briefly and found it more user friendly than GWD, however the extra overhead of the edge runtime added unnecessary file size to my ads. I also find my markup becomes bloated and polluted with confusing id's and class names. I have much more control over my html markup when I don't use these tools and can structure my html more cleanly. I prefer to use GSAP as I know it will work across multiple browsers. Using an IDE alone to animate my elements is just too risky at this stage as I'm not sure what browser issues I might face when something breaks or doesn't work. With the extra time it takes to create banners in html5 these days I just can't afford this time to find a fix. I think perhaps over time these tools will improve, or maybe I just need to spend more time using them. Non-rectangular masks, animated masks, robust timeline control and tools (except Flash IDE), control over animation platform in the case of using an IDE. it has come a long way, if only there was a blending tool option. otherwise it's doing great. They are all deficient in different ways. Google Web Developer is janky to use and when I used it, it only supported chrome. There are other tools but they're not so flexible and cost a lot of money. I'll hand code these and get all the power, flexibility, file size, and compatibility I need for now. Tools need: -Compatibility across modern browsers -An IDE that generates ads in small file sizes GWD is the closest thing I've seen to a potential industry standard but still lacks quite a bit. Pros: - Intuitive Interface - 3D support (designer friendly) - No preview of file size when authoring - Scripting should be two screen from the state - more... Cons: - UX - Preview on multiple browsers/devices (Hype does this) - Owned by a single network, browser vendor, and company - Can we build API's and templates into it for our own specific needs? - No ties to webfont foundries Awesome! SVG draw plugin is buggy on IE10 At the moment, for our workflow, Edge is the winner simply because it is the most polished, and integrates well with the rest of the Adobe Suite which is widely used throughout our agency. I feel that EA and GWD are OK, but I have been trying to learn the code by hand so I know whats going on, thats where I think GSAP is really good in helping with the animation! they are ok, but only for rich media. Because most campaign also have a lot of 40kb/50kb versions next to the RM versions and they do share some animation/timing/assets. It's better to skip them and make all banners with pure code. Edge for instance is not transparent enough to extract a 40kb version and therefor useless selector, and animate. this is what we need Edge itself is running too slow on my hi - end machine (it's an Adobe bug), so I can't use it at all. Flash now can export to HTML5 but it's creating files that are too big. The ability to do masking the same as you could in Flash seems to be missing from HTML5 tools. I don't use them much. I'm more of a programmer, so if I don't have frame-by-frame tools, I'll just make do with coding. They all include a runtime, and GWD is so so so terribly hard to timeline animate that I would rather just hand code things with greensock. Easy conversion of flash animation to greensck code. A timeline in your inspector, which Chrome has now but it doesn't work fully yet. I find them very basic and clunky. I don't like any of those tool. Best ist to Code by hand. I like the flashtalking API since it comes with eventlisteners and also functionnaming that ist close to the actionscript 3 standard. Also GSAP is great. Best think is TimelineMax. Thought it would be nice to use TimelineLite and having some features available like repeatDelay all eventlistners etc to load if necessary. Important is also feed loading, fonts, preloading. Best feature would be polite loading component, that is lightweight. Yet to investigate fully The only one that isn't clunky is flash. But most places don't like it. Also flash canvas has no video integration outside of code. Edge handles video very well but the interface is not as smooth as flash Support (from Adobe's end) for Edge Animate is waning. Google Web Designer is still in Beta. Flash Pro only exports to canvas. Raw coding has been better for me and my team, as it doesn't rely on an IDE- when passing the files around we don't have to worry about everyone having the same software. Do to the Canvas not being useful for banners, and that Adobe Edge Animate is not often accepted, Flash is my familiar IDE using TweenLite. I still have to produce Flash banners and so I use a workflow that accommodates both. They lack proper masking, motion guides, blending modes, etc that Flash used to provide out of the box. Specifically with GSAP. Love it! Intergrated and geeked out back in the day with Flash while working in Advertising. Now the intergrating with HTML5 is simple and predictive. Love. Recommending constantly. To much garbage code added... Don't want to get stuck with one at this point so I built my own. Clean and totally integrated GSAP with Edge Animate or another simple visual timeline editor that uses GSAP as the engine. Maybe use Edge to place elements on the stage, and some motion, and use GSAP within EDGE to do the amazing animation, timeline stuff Tools today arent very designer friendly in contrast to flash, especially when the ad has to be packaged and delivered to the media agency and various services requires ekstra html and javascript coding skills just to add a clicktag. I am moving away from all kinds of animations For an animator who is dont want to learn HTML5, there is not much out there. Generally the code created by these platforms is bloated and messy at best. Hype seems to have the leanest code, and the IDE is acceptable to use, similar to Flash. But none of these are really usable for web banners IMHO due to the file size limitations. Very limited capabilities. More that a bit of sliding and scaling is not really posible. Edge - has a good IDE, but the run-times are too big. Flash - is the best all-rounder, but Adobe has all but abandoned it, so new features aren't happening really. The dev team is very small. Google Web Designer - sucks. Heavily pushed by Google/DoubleClick, but so rudimentary, it's laughable. Hype - slightly better than GWD. Flash -> Swiffy - works okay sometimes. Large files, uneditable source. Google is secretive about it's development/progress. Hand-code Canvas or SVG/DOM- flexible, but highest skillset requirement, long production times, and annoying DOM limitations (e.g. non-rectangular masking) Edge and GWD are terrible. In them, editing complex, key-frame animations is at best a total pain, or more often impossible. If, for whatever reason (time, budget, complexity, cross-browser compatibility, etc.), I can't build an ad from scratch using HTML/CSS/JS, I'll animate in Flash and output with Google Swiffy...but this fall back is a last resort. The robustness of the Flash timeline tools hasn't nearly been replicated in any HTML5 IDE that I've tried. None are as good as flash. They need to have powerful text editing tools and live preview. Awesome. Supported in all browsers. https://www.animatron.com. None so far. There is no good ones. I think the industry is having a hard time switching from flash because there is no good substitute. We tapes got replaced by cd's, no one had to call for an end to tapes. People just switched cause CD's were better. I think flash is having a hard time dying because so far I have not experienced a better tool for prototyping and building get experiences. I use flash for timeline and animation and use greensock for dynamic animation that is better suited in code. The combination of both is what is so great about flash. I can't really stand those tools. They haven't really been able to fix my problems. In my opinion they are still way way behind the flash tool chain. They are garbage. Too much disparity between authoring environment and production environment Many tools are too difficult for pure designers. Me as developer, the tools are just an obstacle and do not give me freedom but for designer, the tools do require too much html understanding. Not good enough. It would be great to be able to see your GSAP-animation within the tool of choice-... Good. But Flash Professional is the best one for me. There is no clear winner. They all have benefits, but none has the ability to create very slim code. Adobe Edge is the worst. If your client/publisher doesn't allow third party hosting, you have to upload the Adobes JS Libraries. And they are HUGE. Edge could be great, but lacks the control and finesse you have with Flash. They all lack cross publisher support or, in the case of web designer, is not easy to use. EDGE ANIMATE seems best - but it's commercial, not open source Advanced masking, testing features (loading and animation speed, interaction, cross browser quality, security, etc.) I think they create bloated code which adds unnecessary weight to the banners. It is far easier to make a lightweight, handcoded framework utilising the Enabler API and the different GSAP libraries as needed Edge is robust and versatile. Google Web Designer is poor beta with templates that don't pass QA. Flash somewhere in the middle but we don't use it for HTML5. Code based solutions are not an option as most of our team are visual designers with some code skills and we need to produce ads to very tight deadlines. There is no clear winner imho. You need to know all the tools and use the one that is more suitable to your needs. Unfortunately they are useless for standard units under 40Kb. They are fine for RM units that can accept bigger loads. However most of the tools are not created to be used in such a small creatives? with the 40k restriction. Very poor. Timing scripts for animations would be good. Standard way of componentising animations would also be good. Check out BannerFlow. I like what they're doing. It is exactly what I need as a production Tool. Flash is too complicated not efficient enough. I'll have to look into the others more carefully. Dont like them. They always need more code and scripts to make a simpel animation. The best of those three is still Flash because its more developed the last years. GWD crashes all the time on mac. I see video as the best solution for media on the web. I haven't really used any animation tools for HTML5. I have been using shift.js as a tween engine Most are in an incredible sorry state. They don't have real timelines, don't account for browser based issues, most don't work in IE10, They don't allow easy integration of custom code. The only one we have found useful is using the createJS output from flash since we can integrate it into our regular workflow. Have not been using these to make HTML5 animation. - Sizmek - Don´t like - Google Web Designer - It´s ok, but with some libraries it crashes - TumultHype - Works ok, only for IOS - Adobe Edge - Works ok but looks as first Flash versions or After - Effects. also it is closed and creates its code - Flash CC Canvas - It fails when you want to do complicated things (3d, Blur filters, masking, etc) - Google Swiffy: Works really well, but weights a lot and increases CPU - Sparkflow: Really nice but not too many penetration - Celtra: Just centered for mobile Animation library. Mostly things that can be dragged, dropped, and tweaked. It needs to be quick so yiu can get your point across without having to dale with so much code cause you start to loose the rythym of a 15 sec animation. Maybe a plug in such as implementing ease.js chart as a plug-in for notpad++ or sublime. Hand coding is still by far the fastest, especially when using GSAP. Flash seems to package any export with CreateJS. I'm looking for a way to export simple vector animations without additional bloat, for instance if a Flash vector animation is 20k if exported as SWF, it would be amazing to get a basic js file that is 20k that I can load in and control as an asset, not the full banner. Having used both Google Web Designer and Adobe Edge, I still prefer Flash. Neither of the other tools feels as polished or as friendly as the flash ads I use to create. Adobe Edge animate: - Exports a standard Js library (Edge Includes) of 100Kb... Google Web Designer: - Beta, clunky but with potential, good for BASIC animations and banners. - Works really well with Double Click. - Templates are cool. If Google Web Designer had an update, included some features common to Adobe products like Edge, added copy and paste!, and had some inclusion on GSAP we'd be onto a winner. I'm not a fan of any of them. Seems each has it's issues and when opening up banners that are made in one of these I want to pull my hair out. With GSAP, there's not much reason to rely on an IDE. they seem pretty fledgling..and limited for the most part, I think everyone still trying to figure out how to bring flash movement to HTML in a way that the millions of FLASH devs out there will latch on to. Its the wild west in terms of whos going to come up with that killer app! adobe edge is highly visual and reminds me of flash in a lot of ways.. BUT they tend of push the timeline features when I am comfortable with as3..it feels like a step backwards for me in this regard. that being said, it is versatile enough to allow greensock and code based movement also. This is what I tend to used quite frequently. the output is also pretty "clean" (readable) when you revisit it at a later date. Slowly, very slowly, getting there. Must haves: Serious coding level, flawlessly integrated in visual layer. Easy & customizeable library integration They are not predictable, they build with bloated numbers of files. We've looked at some tools which require a purchase of a media buy as well---which is not possible in our case. I have a lot of different formats to create. So my workflow to achieve that in short time is to create the banners in PS, export the layers by hand Import them to flash and write a gsap as3 script to do simple animations. I would love to have this kind of workflow for flash banners too. But I have no idea yet, if that exists already. We aren't allowed to use these tool due file size, we still have some 40k html5 banners and the exports from desktop tools are going above it. They are all lacking. Flash Pro has a tonne of features, but not all of them work correctly when you export into the various ways into HTML5. We avoid these tools because they output bloated code and publishers still want 40k ads. Currently, i think these tools aren´t ready for HTML5 animation. do not use very often Most ad serving companies require a .zip of all the assets for a banner ad. It would be great if there was a button that would collect and zip everything up for us. There has not been one that is an easy entry for designers: every tool wants to be everything for everybody. They don't work as well as flash they are all crap, it shouldnt try to hide or obfuscate any code I hard-code with SublimeText, but TweenLite/TimelineLite is hands-down my best tool for animating banners. I wouldn't have had nearly as easy a transition, or gotten the results I needed, without it. THANK YOU!!! I love GSAP from the little bit I have used it. But as for the desktop animation tools I have yet to go beyond Flash since the adoption rate of certain CSS/JS properties is lagging. Consistency issues, etc. edit code , dismiss all unnecessary code. I think google web designer isn't ready for public use. It's buggy and the developer/code view is less effective than Notepad, of all things. It's not even a real program, it's an alpha app that doesn't use the OS' native chrome or UI. Edge has masking which is fantastic, and I haven't used Flash to build HTML. However, all these tools have timeline animation. If there were some miraculous way to incorporate Greensock into the timeline - say, set up a greensock tween with all the properties and fantastic easing - and see that translated into cue points on the timeline, that would be amazing. It would bridge a gap between people who know JS and HTML and those who are more interested in design than code. n/a forget about IDE's and let Flash Designer die. Learn how to code or get another job Edge Animate is currently best - but development of Edge has slowed down (last update has only one feature added!), and there is a good moment to beat Adobe in this field. Love them, they're great! They aren't as effective as Flash but any stretch of the imagination. All of them everytime are trying to make the most easy way to work with their softwares. I'm working with Adobe (Flash, etc) for many years, and I feel confortable working with them, is my clear winner. I love Edge Animate for general animation. they write horrible bloated code. Haven't tried any! I find Dreamweaver easy to work by going back and forth with referenced documents (.js files) but setting things like coordinates is a painful manual process! Most are missing at least one feature. Google web designer has terrible support for webfonts. None are great at shapes and masking. See my answer above. When Greensock came out, I stopped using the timeline entirely, except for setting up the elements on the stage. I just use code to move everything around. All the current desktop tools seem to me like crappy versions of flash, that produce some wack looking code. As a developer first and a designer second, I distrust all WYSIWYG editors of all kinds. poop Ok. Transparant video support. This is the one thing missing to completely replace flash Faantastic, just huge on filesize. I can only use them if my filesize permits. Otherwise the best out there. I've been using GSAP for the last 10 years. Not a fan. I like to work within custom js/class framworks within sublime text I mentioned everything above. Web Designer & Edge are so primitive and limited, I feel like it's fast just to hand code and use GSAP. Flash's HTML5 canvas is nice, but CreateJS adds so much weight. I don't care for timeline editors. I want to TimelineLite everything. Edge is best but bloated file sizes. I think they are great. Edge looked promising but it looks like development stopped. Also didn't have GreenSock on board Google web designsigner timeline interface doesn't work nicely. Flash exports to big files. Biggest problem is when customize your banner outside the tools a d then going back to te tool to chance for example a text. Usually fxxxs up your custom code. They are not as robust as flash. I prefer to handcode my files. I have some coworkers that use GWD, but it takes to long to make revs. Google Web Designer is good for very easy banners. For banners with complex animations we've had much success with animating in flash cc and exporting to canvas. Adobe Edge Animate is great. I love it. But it needs to integrate with GSAP better. I think they have a long way to go to become usable in a similiar way to Flash (in terms of ease of delivery) I'd like to see the inclusion of GSAP in these tools as well. They are all horrible. They spit out a rat's nest of code and blow up file sizes. PointRoll actually wont even allow code produced from these types of tools. Instead preferring hand coded animation from the agency or assuming the responsibility themselves to hand code the animation. Sizmek forces you to use their stupid HTML5 builder. DoubleClick has their own tool but it is unclear if they force you to use it like Sizmek. Either way, I would rather hand code it, or use a tool that outputs lean markup in HTML or SVG and uses Greensock as the tween engine. The out they produce. Bulky code. Have to spend too much time reducing file size. None of them is really perfect. No one builds a sleak library from objects like vector graphics for direct animating on canvas. We would need a tool for minimalistic css3 only animation on the one hand, and enhanced animation with all the JS on the other. Worst are the online editors, which brings the whole workflow of a complete flight to a halt. Animation standards or options. Some use CSS Transforms others don't. Must have: CSS Transforms. What do you feel is missing from the HTML5 banner discussion? Cross-browser testing, specially IE10 should be stopped - totally useless The problem of cross browser/device compatibility issues like transform3d. The lack of specs and basic templates. Each platform still uses there own implementation despite IAB standards. IAB should better update there information. Most networks and publishers are only interested in clients with marketing skills and show a lot of graphs why people should advertise with them. But lack a good spec/FAQ site. If at all available they show Flash 8 clickTag info... HTML5 banners should have an uniform clickTag system like Flash It would be nice to have a simple/lightweight fallback system when features of html5 are not available Seems like most folks doing html5 banners come from the Flash world, and are afraid of learning html/javascript/css. After making the Flash to JS transition myself, I found it was really hard to figure out best practices in terms of setting up javascript files. I was so used to the wonderful AS3 class structure, and so I dabbled with JS prototypes, and have now settled on the "Revealing Module Pattern", http://christianheilmann.com/2007/08/22/again-with-the-module-pattern-reveal-something-to-the-world/ Interesting point about what file size is appropriate for a HTML5 banner. I spent 10 years compressing the hell out of images, trying to educate designers and clients about the limitations of 40k banners then BOOM, its decided that Flash is dead, HTML5 rocks so then the publishers allow a 150K+ for HTML5 banners without polite loading. The Clients should purchase their brand fonts in webfont formats, and they should make them available for web usage.My biggest issue right now is as a developer trying to help my designers transition to HTML5. I think the push to get rid of flash was fairly premature in that people wanted to get rid of flash but the only viable alternative is a non-standardized still in the development stages language that it's better than it was a year ago but still doesn't approach what you were able to do with flash. So now I have designers who are scared that they are going to have to learn CSS and JavaScript and html in no time flat when they don't have any programming skills or desire, and since there's no good IDE for them to use their options are limited. All of this while clients still expect to have the same level of animation and interactivity in this new environment that they have with flash and they still expecte it within the same file size limits. Basically clients want brand new technology based on specs that are almost 15 to 20 years old now Popular JS libraries that are potentially cached should not be counted against us for file size. IE GSAP, JQUERY (when needed), etc. STANDARDS around file size, what counts toward file size what doesn't. There's not true spec or clear answer as to files we can develop and deliver. Most of the advertising market is based on specifications which predict flash banners in single files and low sizes. This pattern is a reflection of our past in which internet connection was much slower, and the realtime bidding market works in that way to assure high scalability. As today we're in a transition to a "HTML5 world", strategies to make the changes more smoothly are welcome, as for example merging images to a single spritesheet so that less calls are made when serving a ad. I think specs/standards is the biggest thing that we need to figure out in our industry. What browsers should we be targeting? How do we deal with web fonts? I tried to subset a font I was using a few days ago, but the font license wouldn't allow it. But I needed to use an actual font, because the text in the banner had to be dynamic. the companies involved need to work together (google, adobe, etc) to develop a standard, lowest common denominator solution for html5 banners. File size, compatibility, Flash player still works! (news to chrome: safari tried this already, still use flash fine). Flash was created to have a common playground across the browsers, so you have one unified experience. Yet, Chrome thinks it's a great time to capitlize on getting people to spend more on rich media advertising fees for HTML banners, which are less capable, more complex to build, and a step back in technology. Flash was ahead of its time and if it came out now a days, it would change everything! lol Newer doesn't always mean better. Everyone is so quick to kill Flash and embrace HTML5. The headlines are always "Flash sucks, it needs to die". Most of these people just see the headlines and don't work with both technologies. HTML5 banner production is significantly more time consuming, more complicated, more error-prone, and less efficient bandwidth-wise, and have silly creative limitations (hello blend modes and masking). Agency veterans usually understand this, but everyone else doesn't and is going to learn through bumps and bruises over the coming years as we get this stuff out into the market more. One more: packaging is missing from the conversation. We had SWF, an easily quantifiable banner unit. Now we have a folder of uncompressed assets that get uploaded. One more: fonts. With Flash, we used desktop fonts and just embedded vector data, giving us nice font representations on the web. Now, we have to use webfonts, which the foundries have figured out how to restrict and charge separate licenses for. So, now we're paying a lot of money for webfonts and loading up font files that can be several hundred K. It's a mess. We typically avoid that and just use images. there needs to be standards. the same way iAB ad standards was created. Developing for so many platform, we still need unified testing platform. Greensock makes the browser compatibility discussion mute but the tools required for a non-developer is not there, even with edge animate because edge uses createjs and various browserspecific features so it's not ubiqitous as flash so if there was a visual toolkit that packages all that's need for banners we would be far in replacing flash. I think there is a huge gap between what ad networks think is a creative ad format, and what creative agency Art Directors think is a creative ad. Ad agencies think that the expanding swipe-galleries (with embedded autostarting video) are all the rage, AD-s think in interactive movie FX quality (with fully featured physics-emulation, real time lighting and CMS level database handling), story-telling, synchronised banners are a bare minimum. (And then there is the client, which adds a whole new dimension to the problem). As a dev, I'm in the middle trying to hack the tools to deliver something that vaguely resembles to the overloaded storyboards to fit in 15sec and 40k. All the HTML5 banner demos, showcases, examples I saw from the ad networks are very dull, sketchy and disappointing. (btw, the same is true to their specifications.) ADs can't grasp what is possible to develop only by skimming thru those samples. Some kind of training-ground would be nice where the industry players could exchange information, know-how, ideas, etc. Love the work that has been done to make this compatible with many browsers. Just going to take time and testing to make sure everything is consistent. Ugh. Guidance from IAB. They should have released updated HTML5 recommendation by now but they are sitting on their hands. Many publishers are still applying Flash specs to HTML5. There is a leadership void... a new IAB has an opportunity to emerge if anyone wanted to start their own organization based on HTML5 and mobile advertising. we nee more paticle system generators, blend modes, video sniffers(play, end, ff, rr, cta on a video end), it's good to know code, but it takes away from having to stick with worthless pieces of code when your trying to get your animations across. At the end, no one really cares about the code but how visually stunning it looks. File size and scattered resources and cross browser compatibility, effects. The 4 biggest disadvantages of HTML5 compared to flash. AL That Has To Be A dressed. Some way to visually animate in a timeline based way with Greensock would be ideal. Having animators animate with code does not produce the same results. This is why we often have animators do work in createJS but we would like a system that works the same just with JS animation on divs. I think the biggest issues right now are outdated specs and lack of understanding of the html5 landscape within the industry. ad server plugins like they had for flash. Just exclude set js libraries from the file size limit and utilize CDN's. Only make sense. It would be cool to get bounded animation sequences. For example, a bird never takes a straight path, never holds the same altitude. I can model bounded random paths fairly convincingly adding sine waves with bounded random period, phase and amplitude. (Also works well for things bobbing up and down on water.) Responsiveness. It is soooo hard to make an interactive banner work on so many screen sizes as well as phones. Most of the solution is to just use a stagnate image on a phone that is more square, but then your message gets lost. Not sure of the solution as I have not seen any I am super happy with. Always looking tho. The banner advertising industry is not yet prepared for this HTML5 thing. Ad servers not prepared. Publishers not prepared. Agencies not prepared. They all want to go HTML but the mindset/framework is still based on Flash. Why do banner ads have to be so darn annoying. No one is talking about how flash was a better medium for ads. I do not think that HTML5 will ever be as good as flash was and the fact that we are moving away from flash is not because HTML5 is better but because of how political it all is. Flash was the perfect solution and the only problem it ever had was that the specs were crap and never revised by the IAB, If i could go back to flash i would in a heart beat and I would much rather see apple have to allow flash on IOS than see it removed elsewhere. Lot's of ignorance around file sizes. Publisher specs always note 40k like it was Flash. Maybe last year, there wasn't clarity on best practices from interactive advertising bureau (IAB). I didn't go into this to be a coder. I loved that banners had a balance of everything. Now I feel it's becoming a code game. I starting to lean more into motion design due all this crazyness Agencies and advertisers need to know that in this new world of Flash-less banners we need more file size That html5 is not yet ready today A standard framework from the media companies. Ie 40K use to the the standard for flash, but now no one knows yet. More tutorials on building complex banners like lighbox banners, or expanded banners with video. it would be great to have a "best practice" advice. The future of Canvas element in HTML5 banners. Animating the DOM is not the future. What's the timeline for when Canvas is accepted? There should not be a system that generates code and display. Your tools work great and apply to all applications. I feel like most discussion on the web today is surrounding HTML5 for use in the gaming industry and web development industry. Topics such as file-size have been largely irrelevant until now since HTML5 has become the #1 technology for the ad industry, almost overnight. We need more resources for ad development that help us rapidly and efficiently hit the required specs provided by publishers. Most important, I think, is file size, as well as libraries and frameworks that allow better masking, curved animation, particle effects, and canvas manipulation. 2. what animations are preferred for HTML5 banners in general 3. what basic techniques are used by me to make banners 4. more publishers (Google Adwords also supports HTML5 banners now) Globally there is a big unity problem, some servers needs one html without js inside + 1 js + 1 css + pics, other servers needs 1 html with css and js inline, some accepts CND calls, others don't. Every tool exports the code their own way and it is sometimes difficult to understand where to put your own code. When I do a flash banner I must sometimes duplicate it because 1 adserver wants AS2 and another AS3, the modification is minimal, it's quiclkly done. With HTML5 I need to do it once for google, once for sizmek, one inline, once with CDN call, another without... and it's not a little quick adaptation, it's every time a complete startover. A way to easy program with canvas A clear understanding of requirements (size / imports). The documentation on Google is lacking. Not that the clickTag was ever that clear either I suppose. I much prefer to use greensock in my ads over timeline animation, but am never sure if I will get rejected because of it. Would love a JS equivalent of TweenNano. Maybe dropping IE8 support for a lighter footprint. Been getting some questions/pushback on total file size of banners. File size is too big. All the agency actually want very complex banners. But everytime the limitation is filesize. We have to start to update the boundaries in terms of ksize restrictions. The 40Kb benchmark is not realistic now, it was in the past because it was set based on a specific technology and the average bandwidth of the typical web user. However, that needs to change and take in count the limitations html5 have compared to what Flash offered in the past. If not, we will be doomed to create ugly, and very limited advertising pieces and that will be a pity. At the moment no publisher has any HTML5 specs, also the ad weight is not handled properly across agency. Some only throw the adtags in a tab, use httpdfox and count untill all assets have loaded. this way banners can be far more then 500kbs, especially mutli products/images With a swf it was easeier to say the file size. Even when flash files where loading eternal sources, the file wight that was charged by the publishers is only the initial swf. so you can have a small swf polite loader that loadsall assets. Something like this for HTML5 would be great. Some how Flash had these amazing optimization tools. I don't think any IDE is going to be successful unless they can make neatly packaged exports. I really enjoy working with GSAP and pretty much owe a career to it. Just keep doing what you're doing and I'm a happy developer. Also, I'm feeling a talent strain. Those who continue to only do Flash development rarely make for good HTML5 developers. And I think a lot of skilled developers think banners are beneath them and have moved on to other development. So, I think there's a talent shortage. Nothing you guys can do about that... I want tools! Actually what I want is an Adobe tool that can be used, I haven't had to much luck with Edge or Flash. If Adobe could come up with a better tool that developers can use to create HTML5 animations they could rule the marketplace again. Also Standards, lets start buildign these out the same way an possibly utilizing some cached libraries Who creates HTML banners? Mostly guys with Flash background. Why? Because they are used to timelines, animations, easings and telling a story within a short time. They know it's about a transition and a nice effect to catch attention. Most HTML developers think in states and lack for a sense of animation. Consistency across the publishers, access to runtimes via CDN to not be counted in file size, individual asset optimization, individually creating and deciding on each piece throughout the whole entire workflow. It would be great to have a nice simple easy to use IDE where I can easily layout out my elements. This would speed things up. Video doesn't auto-play in iOS so we need a way around that or to rethink banner structure. Anyway html is not necessarily more effective than flash in terms of advertising. People will still ignore banners and be annoyed by them. Html5 wont help with clutter, and wont help the browsing experience. We need to develop digital advertising that doesn't annoy. The digital ad industry has its head in the sand about this. I used to make banners in flash when there was time to experiment and adding just a little bit of playful user interaction would trigger a positive experience to the ad instead of just counting conversion rates. the client often does not understand that setting up html5 ads costs a lot of time, copy changes are more of a drag than before, and kb's rise quickly. 'You can do the same in Html5 as in flash right?' - yes, but you need to buy different amount of display KBs and expect a different production timespan There's too much talk about what is possible with HTML5 and the latest browsers when lot of that stuff is something you probably shouldn't do now and won't get away with. I think more standardisation is needed although it sounds restrictive. I don´t know... Media booking companies continue to book Flash spots and never offer an html option. As yet I have not published an HTML5 ad. Publishers are also sticking to Flash and not supplying any guidelines for HTML5 flash supply. Reactionary urgency. Expectation that converting to HTML doesn't cost money. Or time. web fonts are a big problem, too heavy for banners. we like to use css animation rather than js, but greensock is great if we're doing both Flash and HTML5 of the same concept Think I've had my fair share of rant above. The thing that is difficult to lose with Flash is the layout tools. I would lay everything out where it is going to go and then just tween .from Particle systems, video cuepoints, 3D properties. File size limit expansion. Standards and testing tools, an email on acid for banners. DoubleClick, Sizmek and the like provide poor feedback and frequently templates and advice that doesn't work in practice. For me the tools need to not only make it easy to use but meet the requirements across major browsers and pass QA without issue. Using custom fonts is still a bit of a problem since DoubleClick doesnt accept WOF extensions. Nothing you guys can do about. I think the biggest thing that has been overlooked in the transition from Flash to HTML5 banners is the major differences in development. The ads are still being designed the same way, clients are still expecting the same level of creative and interactivity, budgets are unchanged, and media / publishers are have not really adapted their specs either. But from my experience, the same banner will account for upwards of 50% more file size in HTML5 over Flash, and can take anywhere from 25%-50% more development time to make. This is obviously dependant on design, but complex designs require much more complex solutions in HTML5 rather than Flash. Of course this will change over time, but this is how it feels to me currently. Take drop shadows on a transparent PNG for example, in Flash this is a no brainer, import the png, compress it with JPG compression, and give it a drop shadow in the IDE with ZERO addition to file size. In HTML5 you either have to save the png with the drop shadow then crush the PNG, or you can try your luck at a non cross browser filter solution. Then dont get me started on fonts! How many agencies / clients own the web font kit version of their font? The point being that the additional challenges around file size and cross browser compatibility / hacks fall squarely on the banner developer, who is quite likely still working within the same budget as before. So currently I'd imagine many devs are losing a bit of cash in this transition period. more real, great art (and artist) is needed to convince the public to this technology I think overall the 40k file limit is ridiculous today especially when you see people load tumblr sites with animated gifs at 1Mb. 1Mb is obviously retarrdedly large for mobile devices, but given the fact that people will wait that long for an gif, they should be okay with a 100kb - 150kb file that animates. Memory is cheap, bandwidth is getting faster, 100kb isn't as much as you think it is anymore, the industry really needs to move up from 40k to 100kb animations generator All the HTML5 ads I've worked on have been built in DCS, FlashTalking, and Sizmek. In doing so, I've been able to use those platforms' APIs to politely load content, thereby getting around small file size limits. It'd be great to have an industry-standard method for polite loading which wasn't platform specific. I think there is no clear "standard" and Google will probably set the bar so low that we wont be able to create the ads that our clients expect. Its also hard for a flash developer to see a clear path of what to spend time learning, what is going to be the main language used to build banners. From my experience from learning CSS, JQuery and GSAP, I am hoping GSAP will be able to be used, as I really enjoy using it and think its probably the best way forward! Keep up the good work :) HTML5 banners are making the whole workflow much more complicated than flash. Cross-device and -browser testing, much more production time, and uncounted problems on the operational side of things. Google and Firefox have dictated we use HTML5, yet ad networks are not ready for HTML5 delivery. Very frustrating to find someone, anyone with specs or tutorials for creating ads to work using whichever authoring environmental you want. So you yield something that works on various ad networks. There is not a definitive tool to work with. Some have cool things but miss others. Some of them are for designers, some for animators, and some for programmers. But we miss one for these three kinds of designers programmers, as we had in Flash For RichMedia Ads there´s no problem as more weight is allowed. For Standard the debate is on and live. We are not sure what´s happening on Sept 1st after Google Chrome announce I wish that media companies and doubleclick would have better templates. Evolution is the biggest problem I see with JS and HTML5. Browser updates are happening all the time and they often break recently developed solutions. The reason Flash works so well, is that it doesn't rely on a specific browser version to work. If their was a way to compile an html page or website with all it's elements into a standalone, that could be viewed in the browser, I think that would solve everything. The good 'ol time line and blend modes... 40KB is no longer possible, we need at least 100KB or more! HTML5 banners are one step forward, one step back. Whatever we gained, we lost big in browser compatibility. In Flash, you made it once and it worked exactly the same for everyone. With HTML5 you spend most of your time adding fixes for other browsers. Clear specs from publishers, a definitive answer on how to serve to desktop, tablet , mobile seperately including desktop ads / ad slots that will appear on mobile because the publishers site is not mobile friendly and still shows the desktop site when on device, and thus desktop ads can be seen on device Why do we need animation software? It is far easier to make a framework just code it - the at least you know what is going on. Also - responsive banners, we should all be making these cross browser consistency. Fonts, animations, canvas data access.. etc... all vary from browser to browser. Animation, specifically character animation, cross browser COMPLEX animation with small vector graphics. You can't hand code that stuff, it would be crazy to ask someone to do that. We have thousands of talented 2d animators that would tear their hair out at the prospect of doing it with code. It feels like they've killed off a tonne of professionals purely because of Steve Jobs personal vendetta. K sizes do need to be a bit more generous. We've seeing them pushed down to 40K. The other thing I wish were not counted against K size is standard JS libraries like Greensock. We consistently break the rules by not including common libraries in our uploaded code but, as I said, it's breaking the rules. We get away with it though. I just wish it were officially accepted though. Mobile support gestures... With Chrome disabling Flash explicitly for advertising, it's a questionable decision. Namely what do they hope to gain? Some special effects are a lot harder, if not impossible in HTML5. It costs more to produce, more to QA. It weighs more in terms of file size. More files to handle. Unresolved specs. Media vendors fighting over territory with their own proprietary tools for HTML5 banner construction. Ultimately, from a production standpoint, video would be a much better option. I can produce literally any special effect I want and use video assets the client gives us instead of trying to emulate them. (I am currently struggling to reproduce the effects in a 40K flash ad procedurally to mimic the kinds of things the clients are doing with their TV commercials... why not just use their commercial video assets?) QA also becomes almost unnecessary with video... (except for the CTAs) I think more, and more agencies will push for video ads. In fact, the only hindrance is that video buys cost more, but when compared to extra effort and loss of fidelity for HTML5 banners? I think the option becomes more desirable. As a user, I would hate it... Three megs for a banner? NOPE. Ad block that crap. Achieving same results with flash with GSAP easily. Sometimes a visual timeline to place elements on the stage is easier, but I like the power of GSAP and the ability to see all of the code. I don't like how EDGE 'packages' up the javascript and you can't really see it or edit it any where as easily as when working with GSAP. The industry needs to get some specs & standards together ASAP. Sizmek let's be build units however I like, but Google Adwords only accepts units built in Google Web Designer? BS. Fonts are a huge issue. Creatives and clients have exceptions of seeing their brand fonts in ads. Google's "Font Locker" can't come soon enough. I would like to see which way developers are choosing to animate, css, js or svg One minor help would be the ability to see the exact length (in time) of the animation rather than have to manually calculate it or time it off the screen. This is not a big deal, but since most banners must be 15 seconds or less, it'd be nice to easily see a running count of the time when developing. I'm glad browsers are starting to block Flash. With Chrome announcing their plans for a block in September the industry is finally starting to prepare. Flash was really cool but we've all seen poorly programmed poor performance examples. It's time to move on. I really think people should start embarcing straight up code, and those code pen examples are a great start. That being said, there is still a large market for a friendly user interface / timeline HTML5 creator, espeically for people just starting out. Flash had a good balance between the two. responsiveness I think a sheet of properties that you can animate with and without the CcSplugin would help. I'm still vague on that. That it's not just about ad banners. It's about all forms of timeline animation and how to properly fit and make them responsive and reliable. Someone please give us a real world tool we can use for our clients. Right now we are kind of left hanging. Whether or not you can link out to the JavaScript's CDN or having to include it with the files that are uploaded (can help with file size.) Obviously custom web fonts. HTML5 banner discussion as a whole. File size limits. Converting text to png or svg. Whether to use javascript or css animation. There's plenty more to add to this! Browsers. And their support for essential features. Following standards. Publishers. More websites should discourage the use of banner-blockers. Mostly same as the 2nd answer: That most of the content providers in Norway do not allow GSAP. I think they are trying to limit over-animating stuff, which may affect sites on mobile devices. Guess this is something they have learned from using Flash. The fact that when it comes to bang-for-bucks for file-size and compelling, high-quality animation (on desktops at least) Flash is still the best, most mature tech. there should be animation presets, like a typical wobble for CTAs, also motion blur and glare effects.. and better/easier masking Just as above really - standards (I think this should also be the case for e-mail marketting - but that's a different issue) PLUS I would welcome an open source (or even avordable) IDE with some sort of front end and timeline likne EDGE animate has but with decent core JavaScript integration - the code side of EDGE sucks Transparant video support. This is the one thing missing to completely replace flash how to make a useful experience instead of a shouty and annoying one. I have no idea how to have the same, or different, easy workflow that I'm used to so far. So that's my biggest concern. The overall simplification of banners that is happening to "upgrade" to this new tech. We have taken great lengths to educate clients and brands on the new limitations and why specs now play a larger role in that conversation. Getting universal specs would be a huge step, then getting a great animation tool build for HTML5. I mentioned everything above. I want a nice WYSIWYG Editor for HTML5 Banner Educating the traffickers that grow up with Flash. 1) SPECS SPECS SPECS 2) We need to establish one spec that we can use for single size banners, and perhaps another one for truly responsive or multi-size banners. 3) Maybe a frontend js framework like angularjs could be used to help bootstrap banners for certain sizes, so we have 1 banner ad on the ad server that just sizes itself to wherever you put it. Oh yay - a rant! I really feel file sizes need to be discussed, most of my publishers are only accepting 100k unzipped units. This just isn't enough space for a decently creative unit. It just seems there is a huge disconnect between publishers, traffickers, and developers regarding how much space these units should be taking up. CDN support for animation libraries. Sizmek & DoubleClick will not allow this for X platform and support reasons (so they've told me). So I have to bundle up GSAP with each banner. Seems nonsensical when they're both using ad builders that utilize GSAP. canvas, we need a way to have keyframe animation but that can be loaded as an external asset just how we used to do with secondary swfs. We need a way to apply image sprints to a canvas object and control it like a movieclip. Also most vendors have a 8 to 10 file limit and they are not accounting for retina display. Most vendor dont support folders, so we need to have everything at the same level, makes it a mess to work with. Not enough discussion. Also, most of extremely poor quality. Hard to justify time and effort to clients when wanting to make something great when their expectations are so low.

Animating SVG with GSAP

Mon, 04 May 2015 17:54:00 +0000
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 we cover some of the things that GSAP does for you and then we have a list of other things to watch out for. This page is intended to be a go-to resource for anyone animating SVG with GSAP. Outline Challenges that GSAP solves for you Scale, rotate, skew, and move using 2D transforms Set the transformOrigin (the point around which rotation and scaling occur) Set transformOrigin without unsightly jumps Transform SVG elements around any point in the SVG canvas Animate SVG attributes like cx, cy, radius, width, etc. Use percentage-based x/y transforms Drag SVG elements (with accurate bounds and hit-testing) Move anything (DOM, SVG) along a path including autorotation, offset, looping, and more Animate SVG strokes Morph SVG paths with differing numbers of points Tips to Avoid Common Gotchas Limitations of SVG Browser support Inspiration Awesome SVG Resources Get Started Quickly with GSAP Challenges that GSAP solves for you GSAP does the best that it can to normalize browser issues and provide useful tools to make animate SVG as easy as it can be. Here are some of the challenges that using GSAP to animate SVG solves for you: Scale, rotate, skew, and move using 2D transforms When using GSAP, 2D transforms on SVG content 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}); Since IE and Opera don't honor CSS transforms at all, GSAP applies these values via the SVG transform attribute like: ... 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. 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 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. With MorphSVG, you can Morph 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 or to a different set of points Convert and replace non-path SVG elements (like , , , , , and ) into identical s using MorphSVGPlugin.convertToPath(). Optionally define a "shapeIndex" that controls how the points get mapped. This affects what the in-between state looks like during animation. Simply feed in selector text or an element (instead of passing in raw path data) 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). Tips to Avoid Common Gotchas There are some things that GSAP can't solve for you. But hopefully this part of the article can help prepare you to avoid them ahead of time! Here are some things to keep in mind when creating and animating SVGs. Vector editor/SVG creation tips: When creating an SVG in Illustrator or Inkscape, create a rectangle the same size as your artboard for when you copy elements out of your vector editor and paste them into a code editor (how-to here). How to quickly reverse the direction of a path in Illustrator (Note: If the Path Direction buttons are not visible in the attributes panel, click the upper right menu of that panel and choose 'Show All'): Open path: Select the pen tool and click on the first point of your path and it will reverse the points. Closed path: Right click the path and make it a compound path, choose menu-window-attributes and then use the Reverse Path Direction buttons. If you're morphing between elements it might be useful to add extra points yourself to simpler shapes where necessary so that MorphSVG doesn't have to guess at where to add points. You can think of masks as clip-paths that allow for alpha as well. When using masks, it's often important to specify which units to use. Use a tool like SVGOMG (or this simpler tool) to minify your SVGs before using them in your projects. Code/animation-related tips: Always set transforms of elements with GSAP (not just CSS). There are quite a few browser bugs related to getting transform values of elements which GSAP can't fix or work around so you should always set the transform of elements with GSAP if you're going to animate that element with GSAP. Always use relative values when animating an SVG element. Using something like y: "+=100" allows you to change the SVG points while keeping the same animation effect as hard coding those values. You can fix some rendering issues (especially in Chrome) by adding a very slight rotation to your tween(s) like rotation: 0.01. If you're having performance issues with your issue, usually the issue is that you have too many elements or are using filters/masks too much. For more information, see this post focused on performance with SVGs. You might like injecting SVGs into your HTML instead of keeping it there directly. You can do this by using a tool like Gulp. You can easily convert between coordinate systems by using MotionPathPlugin's helper functions like .convertCoordinates(). Technique tips/resources: You can animate the viewBox attribute (demo)! You can animate (draw) a dashed line by following the technique outlined in this post. You can animate (draw) lines with varied widths by following the technique outlined in this post. You can animate (draw) handwriting effects by following the technique outlined in this post. You can create dynamic SVG elements! You can animate (draw) a "3D" SVG path. You can fake nested SVG elements (which will be available in SVG 2) by positioning the inner SVG with GSAP and scaling it (demo). You can fake 3D transforms (which will be available in SVG 2) in some cases by either Faking the transform that you need. For example sometimes rotationYs can be replaced by a scaleX instead. Applying the transform to a container instead. If you can limit the elements within the SVG to just the ones you want to transform, this is a great approach. For example, applying a rotationY to the
containing a instead of applying it to the itself. Limitations of SVG The current SVG spec does not account for 3D transforms. Browser support is varied. Best to test thoroughly and have fallbacks in place. Most browsers don't GPU-accelerate SVG elements. GSAP can't change that. Browser support All SVG features in this article will work in IE9+ 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 Chris Gannon GSAP Animation collection is great for seeing more SVG animations made with GSAP. 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 SVG Tutorials - MotionTricks The SVG Animation Masterclass - Cassie Evans Understanding SVG Coordinate Systems and Transformations - Sara Soueidan Improving SVG Runtime Performance - Taylor Hunt SVG tips - Louis Hoebregts A Compendium of SVG Information - Chris Coyier Making SVGs Responsive with CSS - Sara Soueidan viewBox newsletter (SVG focus) - Cassie Evans and Louis Hoebregts 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 Sequence Animations like a Pro (video) GSAP Documentation

GSAP 1.16.x Update

Mon, 16 Mar 2015 20:21:07 +0000
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're constantly improving GSAP to solve the problems you face as a developer/designer. In the recent release of GSAP 1.16.0 and 1.16.1, Draggable got some big upgrades and SVG support has never been better across the whole platform. Here's a summary of what's most exciting in 1.16.x: Draggable gets "autoScroll" What happens if you're dragging an element inside a scrollable container (or page) and you reach the edge? Wouldn't it be nice if it automatically scrolled in that direction for you? Wouldn't it be even cooler if it applied variable-speed scrolling based on how close your mouse/touch is to the edge, and it handle MULTIPLE containers? Wish granted. Video tour Interactive demo See the Pen Draggable autoScroll by GreenSock (@GreenSock) on CodePen. Draggable's new getDirection() method Sometimes it's useful to know which direction an element is dragged (left | right | up | down | left-up | left-down | right-up | right-down), or maybe you'd like to know which direction it is compared to another element. That's precisely what getDirection() is for. Video tour Interactive demo See the Pen Draggable getDirection() by GreenSock (@GreenSock) on CodePen. Easier SVG animation with svgOrigin For SVG elements, CSSPlugin recognizes a new svgOrigin special property that works exactly like transformOrigin but it uses the SVG's global coordinate space instead of the element's local coordinate space. This can be very useful if, for example, you want to make a bunch of SVG elements rotate around a common point. So you can do TweenLite.to(svgElement, 1, {rotation:270, svgOrigin:"250 100"}) if you'd like to rotate svgElement as though its origin is at x:250, y:100 in the SVG canvas's global coordinates. It also records the value in a data-svg-origin attribute so that it can be parsed back in. So for SVG elements, you can choose whichever one fits your project better: transformOrigin or svgOrigin. Sara Soueidan used this feature in her excellent Circulus tool demo. Interactive demo See the Pen GSAP svgOrigin by GreenSock (@GreenSock) on CodePen. For more information about how GSAP has solved cross-browser SVG challenges, see https://css-tricks.com/svg-animation-on-css-transforms/ and for performance data, see https://css-tricks.com/weighing-svg-animation-techniques-benchmarks/. More Draggable improvements Draggable exposes a lockedAxis property so that you can find out whether it's "x" or "y" (assuming you set lockAxis:true in the config object). New onLockAxis callback that fires whenever the axis gets locked. Several performance optimizations were made to Draggable, particularly for transforms and scrolling. Draggable allows you to native touch-scroll in the opposite direction as Draggables that are limited to one axis. For example, a Draggable of type:"x" or "left" permit native touch-scrolling in the vertical direction, and type:"y" or "top" permit native horizontal touch-scrolling. SVG support is better than ever. It plots the rotational origin accurately, for example. Touch support has been improved as well. Bug fixes See the github changelogs for 1.16.0 and 1.16.1 for a complete list. Conclusion If you're already using GSAP and/or Draggable, we definitely recommend grabbing the latest version. If you haven't tried GSAP yet, what are you waiting for? Head over to the Getting Started article/video now and you'll be having fun in no time. Helpful links Getting Started with GSAP Draggable demo and main page Draggable docs GSAP docs Got questions? Visit the forums

Advanced tutorial: CubeDial, a 3D Carousel made with GSAP

Mon, 02 Feb 2015 20:38:19 +0000
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 following is a guest post by Chris Gannon. Chris is the leading authority on using GSAP with Edge Animate. A veteran of the Flash world, Chris has been applying his animation and design skills to many cutting-edge HTML5 projects. We asked Chris to explain to our audience some of the techniques that he uses in his client work and top-selling components on CodeCanyon.net. The concepts he describes have many practical applications and can serve to radically transform how you approach complex projects. Be sure to explore the demos and study the source code. This is not intended to be a step-by-step tutorial. .wide .content p { font-size:20px; } I love 3D stuff and I'm always trying out interesting ways to add depth to my projects. In this article I'll talk about how the CubeDial below was made, the concepts surrounding its underlying mechanism and how some of the solutions I employ overcome some common issues. Ok, so let's get going. Explore the CubeDial demo In the demo below, spin the dial. Notice that spinning the dial spins the cube. You can also swipe the cube and the dial will spin. Both the cube and the dial spin using momentum-based physics. If you are really clever, you may notice that the cube isn't really a cube, as it has 6 front-facing sides. See the Pen Gannon - Cube / Dial by GreenSock (@GreenSock) on CodePen. What's it using under the hood? The core functionality is handled by the GreenSock Animation Platform (GSAP). I always load TweenMax because it includes all the things I need in one script load: TweenLite, CSSPlugin, EasePack, timeline sequencing tools, etc. I use TweenMax all over the place not only to immediately set CSS properties (using TweenMax.set() but also to delay the setting of them, to tween them, and to trigger events not only when they start or stop but crucially whilst they're animating too. Next up is Draggable - a very useful and flexible utility that I use in practically all of my projects now as most UIs need something dragged or moved. Finally we add in ThrowPropsPlugin (and couple it up to Draggable) for that flick/throw/physics/inertia that we have all become so used to on our mobile devices. So the three main GreenSock tools I will be using are: Draggable, TweenMax and ThrowPropsPlugin. The Cube's Structure A lot of you reading this will be visually led developers so below is a diagram of what's going on with the cube (ok it's a hexahedron I think as it has 6 sides). Each face of the 3D object is a
with a background image. Each
has its Z transformOrigin point set a fair bit away from the actual face (behind it) so that when its rotationY is animated it pivots left to right in perspective. This diagram illustrates the 6 faces - their transformOrigin X and Y are simply set to the middle of the faces (50% 50%) but the crucial part is the transformOrigin Z position which is -200px. In the actual code I dynamically work out what that distance should be based on the number of faces but to keep the diagram simple, I use -200px. The dotted center is that value (-200px) and once that's set each face will appear to swing around a point 200px behind itself when you tween its rotationY. By spinning each face around the same point, we achieve the illusion of the entire cube spinning around its center. To programmatically figure out the rotational offset of each face I use this equation: rotationY: (360/numFaces) * i; What wizardry is used to make a 6-sided object look like a cube? There's a simple answer to this and to demonstrate what's going on I have coded it so that all the faces become slightly transparent when you drag the cube. Try dragging and then holding it halfway through a drag - you'll see the other faces are distorted behind (see sceenshot on left). That's because the transformPerspective on each face is set fairly low (meaning exaggerated) in order to 'bend' the other faces behind. I've also added a slider to help illustrate this in the demo at the top of the page. As you drag the slider, the faces' transformPerspective is set higher and higher to the point where if the slider is fully to the right the perspective is so flat that the cube looks more like an infinite slide show. Try dragging it halfway then spinning the dial or the cube. Creating the dial In simple terms, the dial is just a png with some divs with some numbers in them. I do a little loop based on the number of sides in the cube to generate those divs and position them over the dial image. To make the dial "spin-able" literally takes one line of code using GSAP's Draggable. myDialDraggable = Draggable.create(dial, { type:'rotation', throwProps:true // for momentum-based animation }) That's really all you need to spin something. Amazing. However, the dial I use for this project is a little more advanced. I've isolated some of the dial's code in the demo below. Take note of how the numbers stay vertically oriented as the dial spins. Spin the dial See the Pen Gannon - Dial Only by GreenSock (@GreenSock) on CodePen. Using this method keeps everything in sync and it allows for multiple UI inputs - the null object is always controlled by user interaction and its X position is used to determine the rotation value of the dial (if the cube is dragged) and rotationY value(s) of the faces (if the dial is dragged). You can also use it to work out which face is at the front and because Draggable has the brilliant snap function you can ensure that when you release your drag/throw on either the 3D element or the dial it will always animate the null (and consequently all dependent objects) to a position where a face is flat on. Once it's come to rest you can also fire an onComplete event and have something happen - you might want the active/front face to load an iframe or animate its content. Or maybe you'd like a sound to play or you might want to perform a calculation based on the X position of null. Examples of using onComplete to trigger an animation when the spin is complete can be seen in demos for EdgeRotater and EdgeDial. Interacting with the 3D cube Unlike the simplified 2D demo above, grabbing and throwing the cube is a little more involved. The secret here is that you aren't directly touching the cube at all. In fact it would be literally impossible to effectively drag the cube by a face as the face would eventually disappear in to the distance of 3D space and overlap with other faces. It would be extremely difficult to assess which face receives the touch / mouse input for dragging. To solve this issue a Draggable instance is created that has the null object as its target and uses the
that contains the faces of the cube as its trigger. In simple terms this means that any time you click and drag on the div containing the cube it controls the x position of the null object, which in turn sets the rotation of each face of the cube and the rotation of the dial. Its sort of like interacting with a touch screen. There is a piece of glass between you and the UI elements you tap. Where you tap on the screen dictates which UI elements respond to your input. In the CubeDial, the div that contains the cube is like the glass screen of your phone. As you move your finger over the container, the app tracks your motion and applies the new values to the null object. Wrap up Ok that's enough of the complexities - it's hopefully not that complicated when you play around with it and adjust some values and see how things react. And if you're not already familiar with this kind of mechanism, once you've got your head around it you'll probably find you use it everywhere as it can be applied in pretty much all of your interactive projects. So that's all for now - I hope you found some (if not all) of this article interesting and/or informative. Admittedly it introduces the concept of null objects using a fairly complex example but it really doesn't have to be complex (or 3D). The 2D null object demo above might be a great place to start if all of this is pretty new to you as it uses a null object at its most basic level. Dive into the entire source code of the CubeDial Demo. My first draft of this article was peppered with gushing compliments regarding GSAP and I was told to tone it down a bit and maybe leave them until the end. So here it is (it's toned down a bit because I'm quite an excitable person!). GSAP rocks my world and the world of all my clients. If you aren't using it yet you are potentially missing out on one of the best (if not the best) animation platforms for JavaScript/CSS3. Its flexibility, ease of use and performance is light years ahead of anything else and if you're not using it and are curious then I heartily recommend you dive in and see for yourself. Jack has created amazing tools for designers and developers like us and Carl does an extraordinary job of explaining how they work in a simple, relevant and, most importantly, usable way. Happy tweening!

Ease Visualizer

Thu, 15 Jan 2015 00:16:00 +0000
The ease-y way to find the perfect ease Easing allows us to add personality and intrigue to our animations. It's the magic behind animation, and a mastery of easing is essential for any skilled animator. Use this tool to play around and understand how various eases "feel". Some eases have special configuration options that open up a world of possibilities. If you need more specifics, head over to the docs. Notice that you can click the underlined words in the code sample at the bottom to make changes. Quick Video Tour of the Ease Visualizer 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. CustomEase is NOT in the public downloads. To get access, create a FREE GreenSock account. Once you're logged in, download the zip file from your account dashboard (or anywhere else on the site that has a download button). Club GreenSock members even get access to a private NPM repo to make installation easier in Node environments.

CSS animations performance: the untold story

Mon, 05 Jan 2015 10:40:57 +0000
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. There are some interesting (and surprising) performance implications of using CSS animations that aren't widely known. I stumbled across a few of them while running tests for a customer in the advertising industry who is pushing to have GSAP adopted as the standard, so I recorded a screencast explaining what I found. I figured it was worth sharing: Summary Timeline recordings in Chrome Dev Tools don't show the overhead involved with CSS animation of transforms, so people often misinterpret the [lack of] data. Recordings look "clean" with CSS and "dirty" with JS which leads to faulty conclusions about performance. CSS animations of transforms used twice as much CPU compared to JS according to Chrome's task manager. CSS animations caused the main thread to bog down more than using JavaScript animations. User interaction is typically handled on the main thread, making things feel sluggish to the user. It is especially costly if you animate transforms along with almost any other property at the same time. Webkit browsers have synchronization problems. JavaScript was faster than CSS animations on every device that I ran this test on – the only exception was animating transforms in Webkit browsers (and then there's that heavy cost on the main thread and sync problems). In order to independently control the timing/easing of transform components (rotation, scale, skew, position) in CSS, you must create a DOM node for each which negatively impacts performance. With JavaScript, no such workarounds are necessary. (see note below) I love Dev Tools - I'm not knocking it at all. These things are just tough to measure. Do your own tests! Don't put too much faith in Dev Tools or my tests. Use your eyes because ultimately perception is what matters to end users. Smooth movement and responsive UI are both important. Links Raw Codepen test Google's Paul Lewis addresses CSS vs. JS Animations A great article about hardware accelerated CSS by Ariya Hidayat Why GSAP? - a practical developer's guide UPDATE: After recording the video, I did some more tests that showed that one of the biggest contributors to the slowdowns in the pure CSS version was the fact that multiple elements had to be nested in order to accomplish the independent transform component controls. In other words, staggering the start/end times (or easing) of rotation, scale, and position is practically impossible in pure CSS unless you nest things like that, but there's a relatively significant performance tradeoff. When nesting could be avoided, pure CSS animation of only transforms did appear smoother on webkit browsers under heavy pressure and it was basically indistinguishable from optimized JS animations under all other levels of pressure.

Breakthrough: SVG animation with GSAP solves cross‑browser issues

Wed, 22 Oct 2014 17:14:16 +0000
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're excited to announce enhanced SVG support baked right into GSAP's CSSPlugin. Now you can animate the rotation, scale, skew, position (and even change the transform origin) of SVG elements just like normal DOM elements. The chart below illustrates a number of cross-browser bugs related to CSS transforms on SVG elements. Four modern browsers interpret the same basic animation code in drastically different ways. Browser comparison (without GSAP) See the Pen GIFS: SVG + CSS Transform Problems by GreenSock (@GreenSock) on CodePen. Be sure to test the demo above in IE, Opera, FireFox, Safari and Chrome to see equal results. Find out how it all works In order to help a wider audience understand how to get around the obstacles of working with SVG, Jack wrote an article packed with tons of info, animation demos and a video showing all the juicy details on www.css-tricks.com. We're honored that Chris Coyier allowed us to share these enhancements and time-saving techniques with the wider developer community on his highly-respected blog. Get all the juicy details in: SVG Animation and CSS Transforms: A Complicated Love Story. The techniques discussed will surely transform your SVG animation workflow

GSAP 1.13.1 Released

Tue, 29 Jul 2014 15:10:08 +0000
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. Percentage-based transforms (great for responsive animation) Have you ever had to Google "vertically center a div with CSS"? Maybe you used a bunch of jQuery code that measures the width and height of a bunch of elements so that you can center them based on half-width and half-height? Ever used an onresize event to painstakingly recalculate the size and position of multiple elements that you need for a full-screen, responsive animation? We have very good news for you. CSSPlugin recognizes two new special properties: xPercent and yPercent which can be combined with regular x and y transforms to deliver unprecedented positional control. And yes, since these are transforms, they can be GPU-accelerated for outstanding performance. Example: using xPercent for responsive fullscreen sliders / carousels With the new xPercent property you can easily create fullscreen sliders that don't require lots of costly calculations when screens change size, nor do you have to create separate animations for different devices. Notice how in the demo below you can change the width of the black container and the animation seamlessly adjusts. No code trickery behind the scenes, the TimelineMax animation is built only once. See the Pen xPercent / basic by GreenSock (@GreenSock) on CodePen. To achieve this type of centered layout you could use the following simplified approach //CSS to place origin of all elements in the center or their parent .myClass { position:absolute; left:50%; top:50%; } //JS //center all .myClass elements around their origins TweenLite.set(".myClass", {xPercent:-50, yPercent:-50});//handles all vendor prefixes of translateX(-50%) translateY(-50%) //now we can animate myElement's x/y such that its center is 100px,200px from the origin TweenLite.to(myElement, 1, {x:100, y:200}); CSSPlugin accomplishes this under the hood by prepending a translate(x,y) to the normal matrix() or matrix3d() that it sets on the element.
As a convenience, if you set the regular x or y to a percent-based value like 50%", GSAP will recognize that and funnel that value to xPercent or yPercent property for you, but we recommend using xPercent/yPercent directly. Thanks to Gary Chamberlain for prompting this feature. Better RequireJS/AMD/Browserify/Node/CommonJS compatibility We have received quite a few requests to make GSAP work with module/dependency tools like RequireJS, Browserify, etc. and we're happy to announce that as of version 1.13.1, that wish has been granted. So, for example, with Browserify you can require("./TweenLite.js") and it'll work. If you're a RequireJS user, snag a super simple example set of files here. A special thanks to David Hellsing for his assistance. Save kb by skipping jQuery. Default selector: document.querySelectorAll() Probably the most common reason that developers load jQuery is to leverage it as a selector engine but all modern browsers support document.querySelectorAll(), so as of version 1.13.1, GSAP uses that as a fallback (after attempting to detect a selector engine like jQuery). That means that you can do something like this, for example: TweenLite.to("li:first-child, li:last-child", 1, {opacity:0.5}); Without loading jQuery. And more Several minor bugs have been squashed too, so make sure you snag the latest files to make sure you're rockin' buttery smooth 60fps animations. Recommended reading: Main GSAP JS page lagSmoothing() and other performance improvements in 1.12.0 Myth Busting: CSS Animations vs JavaScript Why GSAP? A practical guide for developers

GSAP 1.12.0: Smoother, faster, smarter HTML5 animation

Tue, 24 Jun 2014 15:35:55 +0000
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're excited to announce several new features in the GreenSock Animation Platform (GSAP) 1.12.0 that will increase not only "real" performance, but "perceived" performance as well. The innovative lagSmoothing() feature allows GSAP to automatically heal from CPU spikes that cause lag, all while maintaining perfect synchronization between all animations. And the new "lazy" rendering helps avoid layout thrashing when many animations start simultaneously. Have you ever noticed how scrolling in iOS Safari stops all animations until the scroll stops, and then animations tend to jerk forward? Thanks Apple. The new lagSmoothing() makes it a much more pleasant experience, resuming animations fluidly. These features are already activated by default in GSAP 1.12.0, so you get them "free" by updating. We've created a few demos and videos to help you understand the impact of these new changes. Both features are explained in detail below. Use the demos, watch the videos and be sure to snag the latest version of GSAP. Videos (watch these first) Performance Test of lagSmoothing() and lazy When you click "run test", a tween is created for each blue box to animate it down 150px linearly. The point is to create a "perfect storm" scenario where a LOT of tweens are starting at the same time which would typically trigger the read/write/read/write style recalculation performance killer in many browsers, hammering the CPU initially. Watch how much faster things are when you enable the new features. See the Pen Blog Post: New GSAP 1.12.0 Performance Features by GreenSock (@GreenSock) on CodePen. "lazy" details Some browsers (notably Webkit) impose a performance penalty for sequential read/write/read/write of DOM-related properties, forcing a costly style recalculation for each cycle so it is better to group reading and then writing tasks (read/read/write/write is faster than read/write/read/write). When you tween a property, GSAP must first read the current values so that it can properly interpolate between the start and end values (even for set() calls because they must accommodate reversion, like when sitting on a timeline that could be reversed). Consequently, when you have a bunch of tweens that are all rendering for the first time concurrently (on the same "tick"), each one would read and then write, resulting in the dreaded read/write/read/write scenario. Normally, you'd never notice a difference unless you have a lot of tweens starting at the same time. As of version 1.12.0, when a tween renders for the very first time and reads its starting values, GSAP will automatically "lazy render" that particular tick, meaning it will try to delay the rendering (writing of values) until the very end of the "tick" cycle which can improve performance. And again, this only happens on a single "tick", when that tween records its starting values. There are certain very specific scenarios when it may need to force an immediate render, and it will do so intelligently when necessary. That's why it's called "lazy" instead of "delayedRender" - it's not a promise to always delay the render, but it's giving GSAP permission to lazy-render if/when it can. It wouldn't delay the render if, for example, you populate a timeline with a bunch of tweens of the same object and then you immediately seek() to the very end of the timeline - it'd need to render the tweens in sequence immediately to make that seek() function properly. lazy is true by default for pretty much all tweens except zero-duration ones (and set() calls) because it is implied that those should be rendered immediately, as you may have a line of code thereafter which depends on the new values being applied. For example: //let's assume element's opacity is currently 1 and we want to quickly set it to 0 and report it... TweenLite.set(element, {opacity:0, lazy:true}); console.log("opacity is: " + element.style.opacity); //1, not 0 because the tween hasn't rendered yet! In most cases, you won't need to set lazy:true because it's the default for normal tweens, but if you create a LOT of set() calls in a row (like in a loop of more than 30), and you're aware of the risks (don't write code that relies on the tween rendering immediately), you could set lazy:true. You can also disable it on a particular tween by setting lazy:false in the vars object. Again, you'll probably never need to worry about setting lazy yourself - the default behavior is ideal for the vast majority of cases. And this setting is only for tweens (TweenLite or TweenMax) since those actually read/write properties. You'd never set lazy:true on a TimelineLite or TimelineMax, for example. New force3D: "auto" feature Previously, you could set force3D:true to cause an element to always apply a 3D transform which typically gets that element its own compositor layer in the browser/GPU, leading to better performance during animation. The primary down side to that technique is that it could eat up more memory. So for example, try animating 2000 elements with 3D transforms on an iPhone and then scroll the page - it gets pretty janky. Now, you can set force3D:"auto" which will act exactly the same as force3D:true except that at the end of the tween if there are no 3D transforms necessary (rotationX, rotationY, and z are all 0), it will automatically switch back to a 2D transform. You get smooth animation, and restored memory at the end. Summary We're working hard to make sure your animations are buttery-smooth on every device and in every browser. Download the latest version of GSAP to get an instant performance boost today. Recommended reading: Main GSAP JS page Myth Busting: CSS Animations vs JavaScript jQuery vs GSAP: cage match CSS Transitions vs GSAP: cage match Jump Start: GSAP JS Why GSAP? A practical guide for developers Speed comparison

CSS Animations: Workflow Issues Exposed [Includes Videos]

Sun, 26 Jan 2014 13:40:42 +0000
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. A post by Carl Schooff, GreenSock's "Geek Ambassador" Hot on the heels of the CSS Myth-Busting article, I'm going to take a deeper look into CSS Animations and how they fit (or don't fit) into a modern animator's workflow. This isn't about simple fades or basic transitions (CSS is great for those); Developers who use animation to tell a story or deliver rich interactivity require a very different workflow than those who are simply doing UI transitions. I'm going to show you exactly where some of the pain points are for a typical project and how they can bring your workflow to a grinding halt. Even relatively simple animations like the one below can become surprisingly cumbersome with CSS. Example of a Simple, "Story-Telling" Animation See the Pen GSAP: Full Version Complete by GreenSock (@GreenSock) on CodePen. Seriously, You guys are beating up on CSS Animations again? Really, I'm not trying to be negative for the sake of being negative. It's just that so many developers are looking for animation tools that accommodate their real-world projects and the industry seems to scream "use CSS!" even though the API doesn't adequately serve the workflow of modern animators who are building immersive experiences or animations that "tell a story". Too many people are being led down a path that results in utter frustration, or at least a lot of wasted time. And no, CSS Animations aren't "evil". In fact, sometimes they're perfectly appropriate (see the CSS Myth-Busting article for details). There are CSS fans who craft animations and proudly shout "Pure CSS! No JS!" as if the grueling effort necessary is a badge of honor. The accomplishment is indeed admirable, and we tip our hats to them. But WOW it's a lot of work and doesn't exactly lend itself to experimentation or easy edits. Quite simply, we aim to change the tide with tools like GSAP. The majority of the GSAP API has been shaped by feedback from real developers in the trenches over the course of many years. The process of animation should be fun and inspiring. Challenge! Still not convinced that GSAP is better suited for professional animators? I'm very interested to see how this animation can be built more effectively. Are you in the CSS-Purist camp? Do you prefer to trigger animations with JavaScript setTimeouts? Maybe you have another library that blows GSAP away. Dig in and build the animation I've been using with your own choice of tools. Below are some resources that should make it easy to get started. When you're done, just drop us a line in the comments or in the forums. Full storyboard showing css values for each key frame: http://codepen.io/GreenSock/pen/DzHBs Starter Pen: http://codepen.io/GreenSock/pen/EsAvF Recommended reading: Myth Busting: CSS Animations vs JavaScript (css-tricks.com guest post) Main GSAP page Jump Start: GSAP JS Cage matches: CSS3 transitions vs GSAP | jQuery vs GSAP 3D Transforms & More CSS3 Goodies Arrive in GSAP JS

What's so special about GSAP?

Fri, 17 Jan 2014 10:28:00 +0000
Feature lists don't always tell the story in a way that's relevant to you as the developer/designer in the trenches, trying to get real work done for real clients. You hear about theoretical benefits of CSS animations or some fancy new library that claims to solve various challenges, but then you discover things fall apart when you actually try to use it or the API is exceedingly cumbersome. You need things to just work. .expander { cursor: pointer; font-weight: 400; position: relative; } section .card{ padding-bottom: 6px; margin-bottom: 10px; padding-left: 35px; padding-top: 6px; box-shadow: none; } .expandable-list { padding-left: 0; } .expandable-content { padding: 0; height: 0; overflow: hidden; } .expander-button { position: absolute; border-radius: 50%; background-color: #BBB; width: 15px; height: 15px; display: inline-block; vertical-align: middle; border: 1px solid #FFF; margin-top: 8px; /* vertically center with heading top: 50%; margin-top: -9px; */ left: -8px; margin-left: -18px; font-size: 0px; } .expander-plus, .expander-minus { position: absolute; background-color: #FFF; display: block; } .expander-plus { width: 1px; height: 7px; left: 6px; top: 3px; } .expander-minus { width: 7px; height: 1px; top: 6px; left: 3px; } .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 standard for HTML5 animation replay

iOS 7 Safari Performance: A Step Backward?

Fri, 20 Sep 2013 09:43:19 +0000
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. With the release of iOS 7, I was anticipating some big leaps forward in browser performance. What I found was quite surprising. Is anyone else experiencing the same thing? Here's a quick [and very casual] video showing what I discovered: A lot of people in the industry talk about the benefits of using CSS transitions because they're so much faster, especially with transforms (scale/translate/rotate) on mobile devices. What happened? Why is Zepto (which uses CSS transitions) so much slower? GSAP's performance remains solid in iOS 7 (far better than jQuery and other libraries), but CSS transitions fall flat on their face (at least with transforms). Can anyone shed some light on what's happening? Are you seeing the same results in iOS 7? Also, is anyone else seeing worse performance when altering the scrollTop or scrollLeft of DOM elements? Useful links Speed test Draggable Demo CSS Transitions/Animations vs. GSAP Cage Match jQuery vs. GSAP Cage Match Why GSAP? A practical guide for developers UPDATE: Apple reached out to us and acknowledged the apparent bug and said they're working on a fix. (Thanks Apple)

Meet GreenSock's Draggable: spin, flick, drag, throw, or scroll with "physics"

Tue, 20 Aug 2013 07:00:59 +0000
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. Making a DOM element draggable isn't terribly difficult - there are jQuery plugins and even some native HTML5 capabilities in newer browsers. But generic dragging is kinda boring. What about smooth, natural momentum-based continuation after the user releases the mouse (or touch on mobile devices)? What about imposing bounds and edge resistance and silky-smooth redirection to certain landing values that you provide? Or flick/drag scrolling with bounce-back that doesn't look awkward? Or instead of dragging to change the position of an element, what if you want to spin it? Maybe you even want to track the momentum and let it come to rest naturally or rig it to glide to a stop at a certain value, Wheel-of-Fortune style? Yeah, that's a lot more complex. In fact, it can be a real drag to build (sorry, the pun was irresistible). Draggable makes it remarkably simple. More importantly, it delivers a very fluid user experience on both mobile devices and desktop browsers. Instead of explaining what makes Draggable so special, we built an interactive demo that showcases some of its talents. There are even code samples that update as you change the options. Go play around and have some fun. View Demo

GSAP JS 1.9.0 Released

Tue, 05 Mar 2013 00:15:12 +0000
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. 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: 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 and the new text in a 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 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.