[img-in-video] have you considered a 3rd element?

[noamr]

As I've commented here, animated GIFs cannot be seeked efficiently - they can only be played sequentially, from their current position or from the start.

Given that various <video> features (audio, tracks, subtitles, seeking) would not work for GIFs or would work very differently, sometimes in a subtle way, I was thinking that extending img is perhaps an option that deserves a bit more chance?

e.g. <img src=animation.gif paused oneshot controls>?

(muted is also mentioned but animated images don't have audio...)

I agree with the explainer, though, that it feels a bit tideous and inconsistent to learn new terms for negative autoplay/loop values.
So a 3rd element might make this a bit nicer?

<imgclip src=animation.gif autoplay loop controls> (actual name a strawman), which takes everything from image, but autoplay/loop/controls semantics and defaults from video, and doesn't require all the baggage of video features that can't work for animated images anyway? Perhaps also a restart function rather than a full-fledged seek, or a way to control playback-rate that is an absolute frame-rate rather than relative to the original content, and a way to query the content's frame rate?

Anyway, there are tradeoffs either way, and this is not a strong support or objection for either direction, but rather considerations that I felt were missing in the explainer.

[noamr]

This also ties back to the alt issue,
In so many ways a GIF is an enhanced image rather than a simplified video, perhaps the platform should expose it in that way (either enhancing img with new attributes or with a new element that is an img with the missing "clip" features).

cc @lukewarlow.