[teraflop]

All of those criteria are satisfied by a <video> element with the "muted" attribute set, plus a little bit of JS if you want to be able to pause the video when it's scrolled out of view or the user is looking at a different tab.

I don't buy the argument about stealing bandwidth. A 50MB GIF is just as much of a bandwidth leech as a 50MB MP4.

[derefr]

It's the image-hosting ecosystem. An animated image format needs to be accepted for upload by public image-hosts; it needs to keep its animated-image semantics when hotlinked and displayed "raw" by a browser; and it needs, needs to work when hotlink-embedded inside an <img src=""> element.

These are all things that are true of GIFs, and aren't true of any other video format. (And this doesn't even address the fact that many people use GIFs for the combination of animation and transparency, which <video> doesn't currently offer.)

The image-hosting ecosystem also naturally deals with the bandwidth-drain issue: image-hosts don't want their bandwidth stolen either, so they have a cap on upload sizes. By allowing just <img src=""> embedding, you naturally lean on the image-hosting ecosystem's bandwidth economics to protect your users.

By allowing arbitrary <video> embedding, though, you invite the nascent video-hosting ecosystem, which has achieved a different balance: far looser bandwidth limits, but far stricter caps on concurrent requests (e.g. the Dropbox-Public-folder model.)

[rcxdude]

There's one specific case which is close to impossible with 'video' formats: referring to animated images in CSS. This is quite important for certain sites where users can modify CSS but not HTML.

[zachrose]

Except that with a muted video, you need to communicate to your forum users that yes, they can upload a video, but it will be played back without sound. It's a different thing.

[archagon]

Can it autoplay? According to others in this thread, the answer is no, and that's pretty much the whole point of a GIF.