geedix

Safari is caching the text as a bitmap to animate, to save on CPU effort. If that bitmap contains the info of the large size, it will look sharp as it scales. So, take the big version, shrink it to start, and scale back up: https://codepen.io/geedix/pen/MWyMNGz

I specialized in banner production for many years, but it seems like that work has been automated or off-shored to the point that it no longer exists in the USA.

What do you use to play a swf file on Android? To my knowledge, the format isn't supported. Certainly not for ad banners, at this date.

This probably isn't helpful, but can't you drop support for iOS8? Apple did. This article says Jan. 2017 is the right time to drop iOS8 support - https://medium.com/@peter.lafferty/when-to-drop-ios-8-b2bd1edd3e91

This would be doable in many ways. I don't see why you would need DrawSVG for the example you posted. It could be a simple linear tween in Animate, or with GSAP, or with GSAP in Animate. One possible issue to consider, if you do want to use DrawSVG in a banner, is that unlike the core GSAP library, this plugin won't already be hosted on the ad server's CDN. You would have to include it and the file size would count against you.

If you're talking about ad banners, then an iFrame is usually the way that's done. SEO isn't a concern for ad banners - - they aren't indexed by search engines anyway. As far as slowing your site: not just weight, but also CPU usage can do that. Since you're using GSAP, chances are you're okay there too.

After several years leading the banner dev team at AKQA San Francisco, I have moved to Albany NY and am available for projects. http://jbradleyjohnson.net/work/

TL Lite works the same in Animate CC, but you can't use CSS selectors like I did. You might have problems if you're trying to tween something on the Animate CC timeline at the same time that GSAP code is moving it, so pick one or the other.

This should work, you just need to adjust the timing. If it's TimelineLite, they happen in sequence until you subtract some time from the 2nd tween. https://codepen.io/geedix/pen/mdbwGYE?editors=1111

This is an interesting question to me, having based my career on animating banner ads. I think it is easier to make mistakes in animated ads. You need a persistent CTA and very brief, concise messaging. We once did a series of elaborate animated ads for Old Navy, and were told that they ended up just running the static backups when it was found that they were outperforming the animations.

I forked your demo and added SVG boxes: https://codepen.io/geedix/pen/WBWvva?editors=1111

You can definitely target SVG with TimelineLite. Did you give your <g> elements the same IDs that your divs are using here?

If these are your specs - https://advertising.amazon.com/resources/ad-policy/en/technical-guidelines - you can have up to 10 server calls. You might want to put some images into spritesheets. I wouldn't recommend base64 images in banners, due to file size like joe_midi said.

CPU issues tend to be a huge concern in our banner development, because we're always trying to make unique animations that stand out from the templated banner crowd. Atmospheric effects, interactive elements, pans and zooms with large bitmaps, nested animations, masked type — these things can cause processors to chug. CPU drag was also a problem in the Flash days, but we could do the kind of vector effects that the OP is asking for in this thread; blurs and filters were available cross-browser, often at the expense of performance.

Hi, Neil. We use both approaches where I work. Often, a hybrid of both in one banner. Some kinds of complex animation, like cartoony things or animated masks, really need a timeline to build efficiently. We recently did a series that used Animate for a logo animation in a canvas tag, but the rest of the banner was html with GSAP. One shortcut in hand-coded banners is to keep all your image files the full dimension of the banner. So if you're building a 300x250, you end up with a stack of divs holding 600x500 transparent pngs, scaled to 300x250 for crispness on high density displays.