bit-depth can't be understood without sampling rate. Just saying a work is "1-bit" is saying close to nothing.
Hadn't thought of it that way but that's interesting. What would sampling rate be in GIF terms? Not the frame rate, because slowing it down or speeding it up doesn't change the size of the GIF. Rather, it's the number of frames. You can reduce the GIF size by (i) decreasing the bit depth from millions of colors to sixteen colors, or to black and white, and (ii) removing frames so that the basic motion is still there without a lot of unnecessary transitions. The GIF we were talking about has the look of a severely-reduced palette but has 360 frames. There is no "original" GIF with full colors that was reduced down to a still rather huge 2.7 megabyte GIF. So (let's pile on here), it's just about simulating Kool 8-B1t Stylezz with no other valid artistic purpose.
1. Brian Droutcour explained what poetry was going to be in a "new media" context. The web has many outlets for literati -- the equivalent of small press publishing -- as well as online versions of established academic journals that continue a tradition of writing and evaluating poetry. So what was an "art and technology" website going to bring to the table in terms of redefining or recontextualizing the poetic narrative impulse? In a cogent essay, Droitcour traced the origins of "new media poetry" back to the early 20th Century avant gardes, in particular experiments in cross-mediation by Cocteau, Gertrude Stein, and others, and then forward through the '50s and '60s with the visually-oriented concrete poets and verbally-oriented conceptual art movement, to more recent blurrings of media in '90s net art. Building on these foundations, Droitcour championed a group of verbovocovisual poets working in electronic media today, such as Erik Stinson.
2. Droitcour's efforts were met with skepticism, and almost no one covered his "wordworks" project for several years. The persistence of his vision eventually convinced critic Kyle Chayka, who covered Droitcour in the magazine Artinfo with a begrudgingly sympathetic analysis. "I wasn't going to just rubber stamp this," said Chayka. "It took many, many posts before I was convinced that Droitcour was onto something."
Nullsleep posts some CSS code that you could add to a web page to make browsers read your GIFs and pixel art correctly when resized. The illustration above, showing an image resized using the bicubic (smooth) and nearest neighbor (sharp) methods, is his; it gets across clearly how ugly "smoothing" can be for an exquisite design. The problem is, 99% of developers can't see this, and will continue to insist that mandatory, "on by default" edge smoothing is what we all want and need when we surf the web. ("Smoothing" doesn't just occur when you zoom, it happens anytime someone codes an image's dimensions to appear larger than the image.)
Dragan Espenschied had told me a while back about a Firefox Add-on for crisp resizing. That's designed to customize the individual's browsing experience ("please render pages correctly kthx"), whereas the code in Nullsleep's post applies this "image-rendering" function on the publisher side, so that various browsers will read your page the way you specify.
It would be best, of course, if the problem could be solved at the source. In other words, make smoothing optional in browsers and educate people about the fundamental differences in how images are displayed on the web (see comments here). As an independent publisher, one shouldn't have to code for every contingency of how each browser is going to read your page. You can custom craft a theme and then two years later you will be prompted to update your theme, which means losing all those carefully worked out modifications. My own solution has been to size GIFs and pixel art exactly as they are meant to be seen, which even meant remaking/reposting some older GIFs.