Have been doing a bit of reading about Google's much-ballyhooed Martha Graham Dance Co. animation. The first thing it brought to mind was Jules Pfeiffer's old series in the Village Voice of a leotarded modern dancer dedicating dances to spring, autumn, mergers, etc (see above). Pfeiffer meant those as satire but Google's illustrator-ish interpretation of actual Graham Co dancers [YouTube] was done with zero irony and lauded by almost every major news outlet. (It even made the AntiSpam press.)
On this page we've been joking that an animated GIF would have done just as well, assuming you had to have this pretentious sequence at all.
However, according to one Google defender, "Google's decision to use CSS sprites and JavaScript to animate them was the most bandwidth-efficient way to create a cross-browser animation."
Where is the proof of this? The CSS sprite sheet is 312 KB - that's big.* The reason CSS sprites are described as "efficient" is they require less http requests to a server than pulling up individual image files--but a GIF also only loads once.
Some background: to animate a CSS sprite sheet you use Javascript code to jump around to different positions on a page of drawings, creating the illusion of movement. The single sheet is used by web designers to reduce the number of image requests made to a server, hence lower bandwidth. According to one commenter, "It is not about file size reduction these days but the number of connections (http requests)..." (More) This YouTube, in German, shows how the Graham animation was done.
Yet a GIF is also a series of coded instructions to animate images loaded all at one gulp. The difference is the pics aren't on a single sheet but are stored as individual frames inside the GIF container. GIFs use compression tricks to minimize colors and avoid repeating information from frame to frame. With no developer skills to speak of I made a fairly accurate GIF of the Martha Graham animation that is 302 KB, smaller than Google's sprite page.
As for the success of Google's animation as a "cross-browser" solution (that is, legible in multiple browsers--GIFs being more or less universally read), as discussed earlier, the Google dancers had noticeable compositing artifacts and were very jerky. That's charming in a GIF but this is supposed to be a glimpse of our Super High Tech future.
What is at ultimately at stake here is forced corporate replacement of a universal, open source means of animation that almost anyone can make (GIFs) vs a type of animation that requires the coding skills of web specialists, who are mostly in the employ of big companies. Any "contest" between the two formats is going to be rigged since Google has a network of local server caches allowing its images to be loaded quickly, as opposed to a single mom and pop website groaning under the weight of image requests.
Additional reading: Martha Graham page about their dance gdoodle.
*Possibly Google's 312 KB sprite sheet could be reduced using gzip or some other compression scheme, yet it seems unlikely that image files such as png and GIF can be gzipped since they are already compressed. (Some say otherwise.) Also, not every browser "gunzips." See, e.g., http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_performanc_3/. [Updated - and see below]
Data URIs (supposedly replacing CSS sprites): http://www.nczonline.net/blog/2010/07/06/data-uris-make-css-sprites-obsolete/
Hat tips to Hypothete, Wizardishungry, and drx.
Update: Drx compressed Google's sprite sheet as a "data URI," converting the already-compressed png to a base64 text file and then gzipping the file. The resulting .gz file is 313 KB, 2 KB larger than the png. This doesn't even include the copious javascript and css commands necessary to animate/display the sheet, so it does appear that Google's animation is, on the whole, less bandwidth-efficient than a GIF. In an email, drx notes that Google's over-engineering of a relatively simple task shows very well the attitude of the "C++ boys" complained about over a decade ago in this essay about the unnecessary hyper-professionalization of the web.
Update 2: One of Paddy Johnson's commenters found what he thinks is a major factual inaccuracy in this post--so major that he spammed her blog with comments loudly and repeatedly claiming that I was guilty of "intellectual dishonesty." (Somewhat like makers of signs on American highways telling you that a tourist attraction is coming up--keep reading folks, the truth is just four comments ahead... three comments...) The gist of his argument is that, (i) with no prior knowledge of CSS or JavaScript, he "fully understands" how to create CSS animations "after less than five minutes' reading" (although he never tested this knowledge by making or posting an animation) and that therefore (ii) I've created a false binary between easy to make GIFs and hard to make CSS animations. It's great that authoring tools for non-GIF animations are starting to appear, but would they enable you to create the "Martha Graham dance"? Many have suggested otherwise. As one commenter noted on AFC, "Google likes to show off what their programmers can do with simple code." Another opined that "GIFs are files that are definitely easier to understand and handle than Google's scripting." A computer science-educated artist that I emailed before posting this described Google's animation as "a brittle coupling of assets and dependent on the state of the HTML document embedding it" and therefore a probable "preservation nightmare" (as compared to GIFs). Much had been written on the wider Internet about How Google Did It. All of which is to suggest that "anyone" couldn't have done it.