I don't see why the "issues" with the <video> tag couldn't be fixed in the video tag?
"Autoplay video is used for ads and thus controlled by browsers" (and <img> video won't have the same development?!) and "<video> can't be saved" (yes, if you use a JavaScript player that interferes with it, if you just link in a file through a <video> tag at least FF and Chrome do have a save option) seem especially nonsensical.
I guess there is some semantic argument for "videos that should act like images", but I somehow doubt that'll happen nicely...
the biggest challenge I've run into is big/legacy CMSes that simply can't get the templates updated to use <video> instead of <img>. It's why we can't have nice things.
> I don't see why the "issues" with the <video> tag couldn't be fixed in the video tag?
You could make that argument for a lot of html tags. <address>, <section>, <figure>. Perhaps this is the safari teams opening argument for a new tag to be added to the spec.
Yup, and Safari may be signaling that <video> doesn't provide the right semantics for the expected behavior. <img> probably isn't the right place either and a new tag might be necessary, but I'll bet the desired code path for the browsers is closer to the img implementation then the video one.
But a GIF was never an image, it's like now they are saying okay we called this video an "animated image" which is somehow different from a video so therefore all videos are images and should go in the image tag.
"Autoplay video is used for ads and thus controlled by browsers" (and <img> video won't have the same development?!) and "<video> can't be saved" (yes, if you use a JavaScript player that interferes with it, if you just link in a file through a <video> tag at least FF and Chrome do have a save option) seem especially nonsensical.
I guess there is some semantic argument for "videos that should act like images", but I somehow doubt that'll happen nicely...