The contract for these could be something like "no sound, default playback in a loop, 30 seconds or less; don't render if any of these requirements aren't met" to make sure people don't abuse it for auto-playing videos.
In both cases, the result is a lack of a right-click-to-save option.
_speechless at the irony
Ironically, GIFs are way larger than e.g. a webm video but are the only format which can be directly embedded in a presentation.
feature requests for Google:
- inline video that auto plays and loops. This is like 1 line of html. Please do this!
- let me drag a video into the slide and just upload it for me and embed it
- or just convert videos to gifs for me when I drag in!!
<img src="foo.mp4">
and have it behave exactly like all other images in how CSS handles it (with auto loop, no controls). This would solve all the reasons people use GIFs in place of videos.Like for example
<img src="foo.mp4" style="width:100%">
should make the image occupy 100% of the width of the parent element and auto-scale the height according to the mp4's aspect ratio. You can't do this with the <video> element without an extremely unintuitive wrapper div.The problem with <video> of course is that there's no way to tell if it's going to play an annoying sound, take a long time to load, change the screen brightness due to HDR features, require a weird proprietary codec, need the browser to render video controls, and so on. So they end up getting blocked from autoplay by default.
I suppose APNG or WebP are ideal for this but it is poorly supported, in that very few tools let you export to APNG or WebP --- browsers actually have decent support for this [1] and Discord uses APNG for stickers.
But it's such a travesty that we're in 2024 and still using GIFs in place of videos. I guess it's not necessary on the web directly anymore, but so many other platforms, like Google, support GIFs but not videos. So we're all stuck encoding into an insanely space/cpu inefficient format just to get something animating.