Hacker News Reader

Comment by mcphage | Hacker News Reader

> browser support for FLIF make this kind of thing irrelevant

I'm not sure it would. The nice thing about a lot of these SVG options (or even the smaller images as well), is that they can be embedded into pages. So not only do you see the image faster, you also reduce the number of remote file fetches. FLIF sounds like you'd still have to hit another server to see anything, even if the thing you see would display before it finishes loading.

View on HN

> reduce the number of remote file fetches

This will become less of an issue as HTTP/2 spreads though.

> The nice thing about a lot of these SVG options (or even the smaller images as well), is that they can be embedded into pages

That's a good point. Though presumably you could embed FLIF data into HTML using a data URI - https://css-tricks.com/data-uris/

Can a data uri be used to store 10% of a file in HTML, but then get the rest of a file? I mean you don't want to include the whole file.

You should be able to encode the first 10% of a file as a data URI, yes.

Maybe you could use something like `srcset` to say "and also load the higher-quality verion from the server"? https://responsiveimages.org/

I think they mean, could you inline the first 10%, and then lazy-load the other 90% (taking advantage of the FLIF decoder's progressive rendering). Which I would have to imagine is a "no" (you would have to swap your 10% placeholder with a whole 100% remote version).

That's what I thought. I wonder what the advantage is at that point, over using, say, an inline jpg for the low quality version.

Currently, browsers don't support FLIF at all. If they ever do support it, what you're suggesting could be an excellent feature to add.

Reply on news.ycombinator.com