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.