{"id":21597,"date":"2017-09-13T20:21:22","date_gmt":"2017-09-13T20:21:22","guid":{"rendered":"http:\/\/responsive_images_guide_part_3_variable_image_encoding"},"modified":"2024-09-07T16:30:25","modified_gmt":"2024-09-07T23:30:25","slug":"responsive_images_guide_part_3_variable_image_encoding","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_3_variable_image_encoding","title":{"rendered":"Responsive Images Guide, Part 3: Variable Image Encoding"},"content":{"rendered":"

Welcome to the latest edition of the Responsive Images<\/a> Guide!<\/p>\n

In part 1<\/a>, I laid out the big idea: a responsive<\/em> image is a variable<\/em> image \u2013 which adjusts itself to fit variable contexts.<\/p>\n

In part 2<\/a>, we looked at the most common way that an image can do exactly that: scaling itself up and down to fit viewports of different sizes and screens with different densities.<\/p>\n

Now, we turn our attention to a different axis of variability: variable image encoding<\/em>.<\/p>\n

What do I mean when I say, \u201cvariable encoding\u201d? Two things:<\/p>\n

    \n
  1. Delivering an image in different formats<\/em> (depending on the end-user\u2019s browser).<\/li>\n
  2. Striking different quality\/compression<\/em> tradeoffs (depending on the end user\u2019s screen, connection speed, data plan, and\/or preferences)<\/li>\n<\/ol>\n

    Let\u2019s tackle both of these, in turn.<\/p>\n

    Variable Formats<\/h2>\n
    \n\nA file whose extension changes between JPG, PNG, GIF, SVG, WEBP, JP2, and JXR\n<\/object>\n<\/figure>\n

    There are many (many<\/a>) different image formats, and new<\/a> ones<\/a> are being developed all of the time.<\/p>\n

    This varied, evolving landscape has vexed the <img><\/code> tag from the very start. To wit\u2014<\/p>\n

    \n

    I\u2019d like to propose a new, optional HTML tag:<\/p>\n

    IMG<\/p>\n

    Required argument is SRC=\u201curl\u201d.<\/p>\n

    [\u2026]<\/em><\/p>\n

    Browsers should be afforded flexibility as to which image formats they support. Xbm and Xpm are good ones to support, for example. If a browser cannot interpret a given format, it can do whatever it wants instead (X Mosaic will pop up a default bitmap as a placeholder).<\/p>\n

    [\u2026]<\/em> I know this is hazy wrt image format, but I don\u2019t see an alternative than to just say “let the browser do what it can\u2019\u2019 and wait for the perfect solution to come along (MIME, someday, maybe).<\/p>\n

    Let me know what you think\u2026\u2026\u2026<\/p>\n

    \u2014Marc Andreessen<\/a> (February 1993)<\/p>\n<\/blockquote>\n

    \u201cJust let the browser do what it can\u201d<\/h3>\n

    Let\u2019s tug on this historical thread a bit and see where it goes, shall we?<\/p>\n

    Mosaic 0.10, the browser that Marc and his team released<\/a> just three weeks (!) after proposing IMG<\/code> to the world, supported two formats: Gif<\/a> and XBM<\/a>.<\/p>\n

    Support for anything else wasn\u2019t suggested until almost a year later.<\/p>\n

    \n

    Hello,<\/p>\n

    Is there a way to include Inlined image not in gif format?<\/p>\n

    \u2014Pini Albilia<\/a> (January 1994)<\/p>\n<\/blockquote>\n

    This innocent, 13-word question ignited a firestorm of responses. Some of them clung tightly to the idea of hypertext<\/em>:<\/p>\n

    \n

    The goal of WWW is to build a distributed, global, hypertext system; not to implement every \u201cfeature du jour\u201d that comes along. The correct, and current, solution to this problem is to simply create a hypertext link to the object in question.<\/p>\n

    \u2014Tony Sanders<\/a> (January 1994)<\/p>\n<\/blockquote>\n

    One response proved remarkably prescient:<\/p>\n

    \n

    As a (still learng) ) HTML programmer, could I just request one possible extension for a future version of Mosaic, and that\u2019s JPEG handling?<\/p>\n

    For a specific (but very useful) category of images, they\u2019re very useful, basically because they can be far smaller as long as you don\u2019t mind a few artefacts. [\u2026] Since bandwidth will always lag behind storage, I think this is quite significant for the \u2019Web.<\/p>\n

    \u2014Andy Holyer<\/a> (January 1994)<\/p>\n<\/blockquote>\n

    But the most important reply, for our purposes, came from a programmer working on Mosaic:<\/p>\n

    \n

    The advantage to using Gifs, however, is that the document will be viewable in all browsers that support inlined images. If you add a new format, the document will only be viewble by a very limited set of people\u2026\nAt least in terms of Mosaic, we have currently only agreed to support gifs\nand xbms on all three platforms\u2026<\/p>\n

    \u2014Jon E. Mittlehauser<\/a><\/p>\n<\/blockquote>\n

    Sound familiar?<\/p>\n

    You can\u2019t use\u2014<\/p>\n