The Need for a Responsive Web Image Format

Images made the first web boom.

If it wasn’t for IMG, a once non-standard bit of HTML proposed by Marc Andresson and put into the relic Mosiac browser, we probably would still be buying encyclopedias on CD-ROMS today.

In that initial proposal, Andresson cited Xbm and Xpm as image formats worth supporting.

Thankfully, browsers have adopted more robust image file formats since then.

Many formats have indeed come and gone, but there are a few we really deal with most of the time: PNG, GIF and JPEG. 

But there’s now a newcomer.

WebP Image Format

Google announced the creation of a new image format, WebP to join their ranks as standard methods for delivering images on the web.

WebP’s goal is to surpass compression file sizes of photographs–a role usually reserved by JPEG. But this JPEG clone has a special talent: It animates! 

So, in essenece, the WebP image format is a merely an evolution of the web graphic, A hybrid of GIF and JPEG file format. 

As modern browsers expand onto more and more onto mobile devices with high resolution displays, the web doesn’t need GIF and JPEG copycats. 

The Problem with Mobile and Images

Problems I discussed when I wrote about the HiSRC jQuery plugin when dealing with a then-hypoethical problem of sending an inline image to an iPad with retina display on a 3G network:

  • Do you deliver the low-resolution, mobile friendly version?
  • Or do you let the iPad 3 have the larger version, but with the longer download time?

Solutions involve sending a serious amount of JavaScript and speed detection tests to devices to be sure of the network speed. 

While I think JavaScript solutions like HiSRC are bandaid on a serious issue, I think it’s better than any proposed alternative.

More Images, More Markup

There’s also an idea of adding another HTML element such as PICTURE as demonstrated in a JavaScript polyfill.

Instead of one IMG element, a web builder is expected to construct several additional lines of code at least one additional line for each device and/or resolution they need to support. 

If Facebook adds 220 million photos per week and flickr 100 million photos per month, those additional lines of code add up quickly. 

What the web doesn’t need isn’t more if-else HTML statements. 

What the web needs is a smarter image format: A responsive image format.

Responsive Image Format

The web needs an image format that, when asked by a browser the server would deliver the right image that contains the right resolution. 

We need an image format that can work in tandem with server and browser to determine the approprirate resolution, pixel 

The interesting part is there is already an image file format that does just that.

It’s called FlashPix.

In a FlashPix file, multiple versions or resolutions of an image are stored in a container.

Which image is delivered by a program like a web browser is a determination that can be made by a virtual handshake between the browser and the web server. 

Why Use This Method?

I’m not saying FlashPix is the solution. I am saying a similar approach should be followed. 

For one, it allows the continued use of the IMG element which is ingrained into the bones, the very marrow, of the Web. 

Secondly, there’s a simple reason why strict coding styles of XHTML was abandoned and loose HTML4 coding practices were instilled into HTML5: 95% of web sites don’t validate.

Asking web designers, bloggers, and non-techies to create multiple versions of their images in order to appease every Android, iOS device and desktop browser seems not only like a very non-standards approach, it’s also not a very practical one.

Content producers that work with the web at least a little bit know the fundamental one-to-one aspect when it comes to publishing images on the web: 

One IMG element somewhat coded correctly results in one image showing up in the browser.

If we go with a solution born from the kin of VIDEO and AUDIO elements–where we do need to balance differing file supoprt due to the browser venders’ turf wars and licensing issues, I believe we surrender a bit of the Open Web mentality for not much gain. 

Another issue is that with a method for inserting images with additional markup means there needs to be widespread change in WYSIWYG editors, their respetive tool bars in Content Management Systems, updated old web pages.

That simply is not going to happen. You will need something on mini-Y2K levels to get companies and organizations to start spending that sort of capital to fix the issue. 

And while I think the retina display is pretty cool, I don’t think this issue rises to that level of concern.

Let Designers Design

If given a choice, I believe web designers would rather export one piece of artwork from Fireworks, Photoshop or whatever their image editor of choice happens to be and let the software compile multiple resolutions into one container file that can then be stored on a server and referenced via an IMG element in an HTML page.

IMG got us this far and it hasn’t failed us yet.

Rather let’s look to make image formats work smarter, work better. 

3 thoughts on “The Need for a Responsive Web Image Format

  1. In the context of this article there are two solutions to the “loading the right image for the job” problem:

    1) A new image format
    2) A new image syntax

    There are advantages and disadvantages to both.

    New Format — Keeps the <img> syntax we all know and love the same. Clean, simple, part of the foundation of the web. But is this new format backwards compatible? Will we need to be muddying markup with fallbacks in order to use it anyway? And what factors does this new image format use to determine which version of itself to display? Container width? Network speed? Pixel density? A Combo?

    New Syntax — It’s more code. It’s more complicated to learn, it’s more complicated to teach, and it muddies the waters of CSS and HTML a bit. But it’s also optional (<img> would still work) and backwards compatible (fallback <img> would be inside new element). The new syntax would allow US to specify what circumstances we want which images to load. It also would mirror the new syntaxes for video and audio which is good for consistency and just kinda makes sense.

  2. @Chris

    I prefer the a new syntax because a new image format would take probably years to be developed and working properly in all devices. Also, we are using already fallbacks in the video for HTML5. So, it would not be very hard to learn and teach because it the technique is already used in other places.

Leave a Reply

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