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...
I was appalled when I first started reading this.
But in reality, it feels quite true to HTML. The HTML author is declaring to the browser the purpose of this asset. This one is to be viewed as an image. This other asset is to be viewed as a video.
The encoding format shouldn't dictate the tag, the content and intent should.
We've been okay with animated GIFs being images for long enough now that we've kind of opted into animated images being okay in general.
APNG is also a very good way to achieve that! No limits in the number of colors, better compression. No patents?
All major browsers now support APNG, Chrome being the last in the bunch :) For example, we use it in our README screencast for https://github.com/wallix/awless
This seems super pointless.
Their reasons:
> 1. Browser performance is slow with <video>
Maybe look into ways to make <video> fast?
> 2. You can’t right click and save video
I never had an issue with this... But if Safari does, perhaps they should have fixed that there?
> 3. Autoplay abuse
Mute the video or remove the audiotrack. If even this in the future gets prevented to autoplay, then I don't see how <img> tags wouldn't as well. After all, they're just becoming the same thing.
Linked site is down - it's a pretty well-written writeup, archived here - https://web.archive.org/web/20171204164627/https://calendar....
EDIT: original author put this up on medium - https://medium.com/@colinbendell/evolution-of-img-gif-withou...
Oh the irony of a site named "perf planet" going down under a little HN traffic.
This page crashes on chromium before you even have the opportunity to read half of the article. I wonder if there is a memory leak or it's just the GIF implementation in chromium.
The crux of the problem seems to be where we encode the information "this video should loop".
We did it before in surrounding HTML structure. The proposal is to now do it different, slightly shorter, surrounding HTML structure. As far as I can see, there's no fundamental difference, just syntax sugar and a battleground reset.
How do we get the video to loop when viewed directly? When set as the background? When saved as a file? These are use cases that .gif satisfies and videos don't, or only awkwardly and inconsistently.
Also note that content is inherently suited or unsuited to looping. It's rarely useful to play a normal video on a loop, or a video meant to loop just once.
All this points to one solution: a new file extension that means "a video meant to be played in a loop". The format of the file need not be any different from a video. Maybe ".mp4l", ".webml", etc.
One of the reasons GIF's are popular is that it's a format with nearly universal support, with no codecs to fuss about. Anyone can see a GIF, and anyone can edit a GIF.
The proposed "improvement" offers the key limitations of GIF without the key advantages, and lacks many features.
Like, what about variable frame rate? Transparency? Not fuzzing out the pixels in pixel-art?
The last one specifically: a great use-case for GIF is capturing screen animations (see https://www.cockos.com/licecap/). Video codecs aren't optimized for this - you won't see the comparison for such GIF's on the linked webpage.
I've floated the idea of allowing various video formats in <source> for the <picture> element. Would allow for the right codec to be selected, and would easily allow for a <img src="foo.gif"> as the final fallback. Might be worth pushing on more.
The article mentions removing the audio track. Is that required for this to work or would it play if it's included or is that just for efficiency? i.e. will Safari simply ignore it if it's included?
Site is down for me so I have no idea if they addressed this in the article or not, but what's wrong with the `<video>` tag?
As a user, I greatly prefer that option since it lets me control playback (via the "show controls" menu option) whereas GIFs (and presumably also mp4 "images") don't.
It’s just HEIF. http://nokiatech.github.io/heif/technical.html
I think we should not deny its future proving goodnees.
If you're interested in seeing this in Chrome, star https://crbug.com/791658
Does it support transparency and 4:4:4 chroma? Otherwise it does not cover all gif use cases. Namely pixel art and sprites.
Animated PNG is probably a better replacement for those.
WebP and APNG are both good formats instead of GIF. But the problem is that Chrome developers stubbornly do not want to add APNG support, while Firefox developers, also stubbornly, do not want to add WebP support. "Thanks" to both those teams we are forced to do such hacks...
Can we please replace image and video formats by something more generic, e.g. bytecode+data?
(We can put the bytecode of the encoder/decoder in some content-addressable remote storage, and pre-fetch/pre-optimize it when necessary.)
Did it get hugged? The website isn't loading for me.
Link is dead. Is it also supported on mobile Safari?
Still no date as input type :(
IE 5.5 supported <img dynsrc=""> back in the 90s.
what other browsers are drinking this cool aid
But .mp4 is a video/... MIME type. Not an image/...
We have <video>, so why not use that?
What next? Utterly ridiculous, Apple.
Unsurprisingly, Apple goes for the patent-encumbered video format [1]. I'm disappointed that Firefox never really had the opportunity to "win" the browser wars and push more user- and developer-friendly formats on the world.
[1] http://scratchpad.wikia.com/wiki/MPEG_patent_lists#H.264_pat... (the vast majority of the patents will expire by 2023, but 2027 is the last probable date that it will be encumbered)