GIF and JPEG weren’t the first images to be supported in web browsers even though they seem to have been with us forever. PNG and its alpha transparency feature took a while for mainstream adoption after it was first noticed. And now Google is pushing for their new WebP image format, but the already glacial pace of image adoption will be slower for WebP.
I see WebP’s as a hybrid of GIF and JPEG without offering any new revolutionary features (like PNG’s alpha transparency). We already have a problem with adaptive/responsive images and it's a problem that calls out for a revolutionary solution.
The problem with our friends JPEG, GIF and PNG is that they are what they are: static, standalone one-trick ponies. They can’t be both low resolution and high resolution at the same time. What we need then is an image file formats that is, in essence, a storage locker.
Storing resolutions
For example, the .mp3 file format isn’t only bits of ones and zeros detailing music. There’s also meta data information inside an audio tag. This is where, for example, iTunes records song information such as song title, artist, album title, year the song came out and so on.
We need to have a file format for images that’s similar. Instead of capturing meta information for the image, which is pretty straightforward, we need to store different variations of the image. One image file might be able to contain a thumbnail image, a mobile friendly image, desktop friendly version, retina display version and print-friendly image.
This responsive image format isn’t just a dream. An image file format already exists that does this: it’s called FlashPix. Developed in 1996 by partners Eastman Kodak, Microsoft and Hewlett-Packard, the image file format was ahead of its time, as it didn’t have adoption in the browser market and seemed to be listless.
Benefits of the responsive image format
One of the benefits of the responsive image format is that it allows the continued use of the img element and just the img element. The img element is ingrained into the bones, the very marrow, of the web. The <picture> proposal went against that mentality by forcing multiple source references to different images to get one image to work. That's a lot of extra work for something so basic.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
Some have said that the <picture> element is consensus-driven, well-crafted and is usable solution (see cssquirrel.com/blog/2012/05/15/the-egotistical-puppet-king-and-i/).
I’ll grant you two out of those three – the <picture> solution had consensus and was well crafted, but it wasn’t a usable solution.
There’s a reason why the strict coding styles of XHTML was abandoned and loose HTML4 coding practices were instilled into HTML5. Ninety-five per cent of websites don’t validate (see dev.opera.com/articles/view/mama-markup-validation-report/), not because we don’t wish them to, but because we’ve coded them that way either from the beginning or over time.
Asking web designers, bloggers, and non-techies to create many copies of their images and write extra lines of HTML in order to appease every possible display scenario seems not only like a very non-standards approach, it’s also not a very practical one.
The solution for audio and video was born to balance differing file support due to the browser venders’ turf wars and licensing issues. By trying to go with a solution born from video and audio elements it was if we wer copying an answer to a unique math problem into another math problem simply because it used the same integers.
There isn’t a need to craft multiple lines of HTML to make one image show up in a web page as was offered in the <picture> element (see www.netmagazine.com/features/state-responsive-images).
Content publishers that don’t code
Another issue is that with a method for inserting images with additional markup comes a need for widespread changes in WYSIWYG editors, their respective tool bars in Content Management Systems and updated old web pages.
That simply is not going to happen. There needs to be something on mini-Y2K levels (see www.computerworld.com/s/article/9142555/Y2K_The_good_the_bad_and_the_crazy) to get companies and organisations to start spending that sort of capital to fix the issue.
The SRCSET attribute
Recently, the WHATWG announced their own proposal after considering the <picture> element (see www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset ). At first glance, this is definitely a more usable, more backwards compatible solution than the <picture> element.
The syntax for the attribute needs work as Jeremy Keith discusses (see adactio.com/journal/5474/), but these issues are easy to addressand – hopefully – are less dramatic.
Save once, images everywhere
If given a choice, though, I believe web designers would rather export one piece of artwork from Fireworks, Photoshop or whatever their favourite image editor of choice happens to be. Then this container file is uploaded on a server like every other image file we’ve used before and referenced via the img element in an HTML page. The only difference is that the server and browser agree on which image in its storage locker should be displayed at the moment it's referenced.
IMG isn’t dead yet
The simple img has got us this far and it hasn’t failed us yet. but the introduction of the SRCSET attribute is a smart move and gets us a little closer to a solution. Now, let’s look to make image formats work smarter and better by building smarter browsers and servers.
The web needs an image format where the server, when asked by a browser, can deliver the right image that contains the right resolution. We need an image format that can work in tandem with servers and browsers to determine the appropriate resolution.
A new image format for web design isn’t impossible. It just feels like that sometimes.
