HTML and CSS Reference
your campaign's end goals and requirements to determine which method to use. However, I can provide a few tidbits
engine of the browser to interpret, parse, and execute instructions during runtime. On the other hand, browsers can
implement CSS3 animations natively in the underlining code base of the browser (the engine). Usually written in C,
C++, or something similar, this code gets compiled to machine language, so it's always present, shipped, and installed
with a browser. This allows CSS3 to often be hardware-accelerated and offloaded to a machine's GPU for intensive
operations like animation, which makes for better-performing experiences a user can notice on a mobile browser like
iOS Safari or Android's native browser.
Between the two, many developers will argue that it comes down to some combination of ease of use,
If you care only about subjective ease of use, the modern Web, and hardware support, CSS3 is a viable solution. Also,
optimization and performance are everything, you should ultimately utilize both to your advantage while taking the
requirements of the campaign and the target audience into consideration. At the end of the day, there are many ways
to pull something off. Knowing one way of doing something doesn't mean it's always the best way at any moment
and for any scenario. Understand who your target audience is and what primary browser they're running. This could
involve some browser statistics investigation on the publisher's part to figure out what their users primary user base is.
I strongly recommend you get familiar with http://stackoverflow.com if you aren't using it yet. If you have
questions regarding this or other topics, chances are you won't be the first one asking.
Finally, I can't perform every test known to man to figure out which animation technique is better in your specific
scenario. I want to empower you to test on your own; in return, do a service to the developer community by recording
your tests with a really great tool: http://jsperf.com . Get familiar with using this if you need to re-create bugs or test
differences between multiple ways of doing something in your script.
requestAnimationFrame, setInterval, and setTimeout?
available in support of IE10, Firefox 4, Chrome 10, Safari 6, and other modern browsers, animation was achieved by
execute the command over and over again, usually until a certain condition was met and stopped the animation. If
for some reason it never stopped, the browser would execute the script forever and eventually crash or freeze (this still
sometimes happens with poorly written scripts). However, since requestAnimationFrame was introduced by Mozilla
and repeated by Webkit, the objective was simple: provide a native API for controlling animations in the browser
entirely. Whether it's a DOM element, CSS, canvas -based, or even WebGL (there'll be more on WebGL in Chapter 12),
the browser will handle and optimize any animations into a single animation phase, leading to higher animation
quality overall. If you have animation looping in a tab that's not visible—say, your advertisement's animation and the
user isn't viewing the ad—the browser won't keep it running and hogging system resources. Publishers should love
this—it means fewer resources to allocate and much less memory usage, leading ultimately to much longer battery life,
especially for mobile devices that support the new approach. I feel Microsoft's Developer Center explains it perfectly:
The msRequestAnimationFrame method provides smooth animations and optimal power
efficiency by taking the visibility of the web application and the display's refresh rate into account to
determine how many frames per second to allocate to the animation. msRequestAnimationFrame
is a very efficient way to schedule non-declarative script animations and should be used instead of
setTimeout and setInterval.