While we’re here, shall we fix file format issues?

WebP is awesome, far better compression than JPG or PNG etc. Modern browsers support it. But, we can’t use it at all until everyone uses a browser that supports it. Because there’s no way in HTML to do fallbacks for non-supported image formats.

Remember when we wanted to use Alpha PNGs but it took years and years because we couldn’t rely on browsers implementing it?

This is an opportunity for us to define a method whereby <picture> could take a selection of resources to use depending on browser capabilty. I.e., if WebP is supported request that file, if not then fall back to a JPG or PNG, as set in the tag.

This would perhaps speed up adoption of WebP, and more importantly allow for future formats to be developed and become usable without the wait for every browser to implement whatever new formats appear and then for the public to all use such browsers.

What do you think? Should we also try to tackle this “short-sighted” file-format behaviour? I would like to be able to save 20%+ on all my images by using WebP sometime before 2020…

22 Responses to While we’re here, shall we fix file format issues?

  1. Anselm Hannemann says:

    Well, there actually are methods for WebP support in non-supporting browsers. One had already written a WebP polyfill and there are same things for video-formats, too. So I don’t think such people aren’t able to write a transcoder for a responsive image format.

    And, of course we will have majority of people using webp-supporting browsers in future.

    I’d really like to have a responsive file format as an alternative to our html5 or the now existing css3 solution.
    I vote for it. So I know many people would to, too.

    Of course, this is not a solution that replaces our html5-syntax but it would be very helpful I think.

    • Matt Wilcox says:

      There are no HTML only solutions to this, and that’s what I am proposing we do :) This would also future-proof HTML against any new formats that may come out, enabling people to start using newer formats with current fallbacks, rather than having to wait years for a sufficient % of users to have NewFormatCompliant browsers to even begin to use the NewFormat.

      Progressive Enhancement / Graceful Degredation for image formats is what I am proposing we get picture capable of.

      • Jacob Mather says:

        I agree, Matt.

        I saw the comments come up in the rss feed and was confused as I thought the proposed solution already covered this instance.

        • Matt Wilcox says:

          The proposed tag responds to media queries to select a given image for that result. It does not allow you to specify a fallback image for that result should the preferred image not be supported.

          No HTML method allows us to say:

          “Use mypicture.webp, but if you don’t understand webp use mypicture.jpg”.

          • Jacob Mather says:

            Why not add a type into like the video and audio elements? If the browsers support it, they’ll use it (as long as other pieces allow it to, i.e. media queries).

    • Jacob Mather says:

      I don’t know how well a responsive file format would go over, because then /everyone/ would have to download all images, which is actually worse than right now.

      I think we’re best leaving the file formats to those crazy compresser people and us just figuring out a solid way to pick which one to use.

      Except for maybe SVG, but then then you lose some advantages over a pure based approach, I believe.

      • Matt Wilcox says:

        I’m not arguing about what we want WebP to do, that’s a topic for a different thread. I am arguing that we sort out how to gracefully degrade to different images should one format not be supported.

        • Anselm Hannemann says:

          @Matt: Yes, it’s a different thread but you’re totally right we need to solve such problems, too.

      • Anselm Hannemann says:

        What do you mean by “everyone has to download all images”? A responsive file-format would feature a mobile-first format and progressively downloads a higher resolution if needed/possible.

        • Jacob Mather says:

          Interesting, I hadn’t considered a ‘streaming’ sort of implementation.

          It makes sense to do it like that if you’re looking from a purely graphical perspective, but when used in the context of the web, that would essentially throw out (and re-invent or cross-embed) the benefits we gain from CSS and the html markup for .

          Let me rephrase: From what it sounds like with the proposal of a special file format for responsive images, we would embed multiple versions of an image into a single file, along with, I would assume, the rules on when to display which version? If that’s right, then you would have to have a separate tool to build/maintain your responsive images.

          Contrast this with the proposed implementation, where all of the data about which image to use, and when, is all embedded in the html that we’re already working in, which makes a lot more sense to me.

          Granted, this is probably the wrong place to have this discussion, and if it is, I’m sorry.

          I definitely agree that this markup could be a great way to handle file type issues, but I don’t know what else we would have to add to get it there.

          Take the PNG issue for example. Even if existed, and it had file type support features, IE still claimed it supported PNG, and it did, though it missed a feature (alpha transparency). Unless it’s coupled with some other system (say, a third party way to add/amend media query abilities), even having a type attribute wouldn’t have helped with the PNG debacle.

          I think in terms of gracefully degrading it’s a matter of the browsers just skipping types they don’t support (same as video and audio now), but in terms of being able to actually fix some of the past issues we’ve ran into, the problem is deeper.

          • Jacob Mather says:

            Quick rethink: I was quite narrow sighted on the responsive image format. While I think it probably isn’t needed for images “in websites”, I’m sure there are many other scenarios where it makes a ton of sense, and I apologize for dismissing those without a mention.

  2. Philip Ingrey says:

    Matt,

    That seems a genius idea, things might get a bit complicated when different image types have different media queries attached (but that would be an odd situation). But on the whole this sounds great as it, like the video and audio tags, would allow for any future format to have a chance at gain traction.

  3. Christopher Schmitt says:

    If we have an image file along the lines of FlashPix, I think we can solve a good deal of the pains with RWD images.

    I’ve written a blog post that talks more about the need for a responsive image format.

  4. Christopher Schmitt says:

    Where can I check for browser chart for WebP support?

    • Philip Ingrey says:

      There’s not really a table of browser support, but
      – chrome and opera support it natively
      – firefox can be patched with a javascript shim
      – and the rest can have it added with a full javascript decoder.

      Based on this, statcounter says that’s 32% of browsers worldwide with full native support.

  5. Pingback: Move on! | Responsive Images Community Group

  6. Anselm Hannemann says:

    Okay, as we cannot address this issue in this group I have written a blog post about the problem. This explains the whole topic and why and how to spread the word to the right people.
    Please help me, making this topic an important point at WebP-community / Google!
    http://anselm-hannemann.com/blog/2012/04/14/a-chance-for-webp/

  7. Kornel says:

    Theoretically you’re supposed to solve that using Accept: HTTP header…

    Anyway, sizes of PNGs can be pretty close to WebP with appropriate optimization with pngquant and ImageOptim.

  8. Jon Wolski says:

    There is an HTML solution to all of this from 1999: the ‘object’ element.

    If you can’t handle content negotiation with HTTP as Kornel suggested, there’s an workaround baked into html4 (http://www.w3.org/TR/html4/struct/objects.html#h-13.3)

    alternate (hyper-) text

    Handling novel content types for replaced content (images, video, etc) is exactly why the object element exists.

  9. Jon Wolski says:

    object type=”image/webp” data=”…”
    object type=”image/png” data=”…”
    alternate hypertext
    /object
    /object


    this comment system is pretty awful for discussing html

  10. Pingback: Thoughts on adding a type attribute | Responsive Images Community Group

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.