New HTML Picture Element To Make Future Web Faster 161
nerdyalien writes: At some point, haven't all web developers spent an unjustifiable number of hours trying to optimize a desktop site for mobile devices? Responsive web design provides a solution: "develop once, works in every device." However, still it downloads multi-MB images and re-sizes them based on device screen resolution. Retrieving optimized images from the server, based on device (desktop, tablet, phone) and the device's internet connection (fiber, broadband, mobile), has always been an open problem. Recently, a number of freelance developers are tackling this with a new HTML element, <picture>, which informs the web browser to download optimized images from the server. The tag will be featured in Chrome and Firefox later this year. Will this finally deliver us faster web browsing on mobile devices and an easier web development experience?
Dupe (Score:5, Interesting)
Kodak had the right idea decades ago (Score:5, Interesting)
Kodak pretty much solved this problem in the 1990s with their ill-fated Photo CD format. JPEG encodes pictures in sequential 8x8 pixel blocks. So once you set the image size and encoding quality (which determines files size), everything from that point on is committed to those settings. By contrast, Photo CD [wikipedia.org] encoded a low-res Base version of the picture (512x768). A double-resolution version (1024x1536) called 4 Base is then created by doubling the size of the base and storing the (compressed) delta from that and the resized original photo. The process is repeated for 16 Base (2048x3072).
Essentially, whereas JPEG stores the picture in sequential translated blocks, Photo CD stores the picture in zoomed blocks - kinda like a fractal. If you want the low-res Base version of the picture, you only have to read the first part of the image file. If you want the med-res 4 Base version, you read further along the image file. If you want the high-res 16 Base version, you read the entire image file. (Speaking of which, there was a fractal-based compression algorithm. But the licensing fees were so onerous it never went anywhere.)
Despite Kodak's eventual demise, they were at the forefront of digital imaging (why they held on as long as they did - they owned most of the digital photography patents). And their engineers put a lot of time and thought into the Photo CD format and future-proofing it.
Re:Progressive JPEG (Score:5, Interesting)
What you'd need there is not file support, but server side support. If you're downloading a single file with all those formats, you're going to have to download everything at once. That's inefficient (important on mobile devices) and slow. Stuffing all the sizes into one container isn't the answer.
Instead, what you'd like is one URL to automatically send you the correct file(s) for your size(s). For example, you could put headers in the http request giving the desired resolutions and the response could have each of those sizes, in preference order. Basically have each image request turn into a CGI request for multiple files. More or less what this new tag is trying to do client side. Of course doing it client side, while less convenient all around, does have privacy advantages- you can't guess the device type from the sizes requested.