Slashdot Mirror
New HTML Picture Element To Make Future Web Faster
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?
of the HTML 5.1 story?
Think about just how much work is now needed to display a simple GUI on a number of different devices. Something that a single developer could once have cooked up themselves now takes teams of designers, UX people, UI coders, back end coders and the rest to do. Really, we should chuck it all out and just start again.
my blog of work misery - http://beastofbaystreet.com
" Responsive web design provides a solution: "develop once, works in every device."
Name one good responsive web design that isn't shit on at least one of desktop or mobile. (And an awful lot of them are shit on both.)
Anything actually good just builds them separately, and lets you switch between them; and selects as default the right one based on screen size (screen not window) Nothing sucks worse than making a desktop window smaller because you just want to keep one part visible while you work with something else and having the site spontaneously implode into a mobile version -- just one of the countless forms of SUCK thanks to "responsive web design".
Back in the days of HTML, they decided that it was awful that the people using dial-up had to wait so long for images to load ... so they came up with the 'lowsrc' attribute to the IMG element:
<img lowsrc='...' src='...' ...>
Or, you could could go with the 2000s route, and use CSS's media queries so that you don't try to push large images down to small-screen devices.
Wouldn't it make more sense to just use a known attribute or method rather than trying to come up with yet another solution every few years?
Build it, and they will come^Hplain.
For this solution to work, not only do you need to implement a new HTML element and get the servers and browsers to support it, people uploading photos (or their servers) need to generate and store multiple size versions of the same pic.
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 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.
Let's see how Internet Explorer can manage to munge THIS tag up.
Or the graphics designer could just optimize the graphics so that they are the smallest possible size in the first place. Then they are the fastest for everyone. Designers, like programmers, are usually used to having the fastest computers and connections so they forget about people with slower computers and connections.
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.
I still have more fans than freaks. WTF is wrong with you people?
There are several, but site I was referring to in particular was mashable.com. It came up at work as an example of "good responsive design" to which I argued that it was in fact abysmal.
These were some of my notes taken at the time (I don't know if they all still apply, but a click glance confirms at least most of them still do)
Chunks of the site can't be reached from mobile at all - how do I get to "Jobs" or "Advertising" from a smartphone?
And on the desktop, parts of the site can't be reached depending on the size of the browser window and we're not talking perversely small either: that "more" popup menu on the desktop starts losing sections outright at around 1100px). 1100px is too narrow! Want a job at mashable? They don't have a section for that unless your on a widescreen.
Worse, if you shrink the page below 1000px wide, you start losing content columns off the home page too -- they're just gone. You can't scroll horizontally to get to them, and unlike the mobile version which displays one column at a time with a column selector to switch, that selector doesn't appear on the desktop. If you shrink your window, you just lose columns. No selector, no scrolling, the content is just gone.
Additionally the column selector names are different from the desktop column headers... "What's new" is renamed "New" for space and that's fine as the translation is preserved. But "The Next Big Thing" is renamed "Rising" for space -- that's a navigation cue that got lost in translation. If I were to say, 'Look for the article under "The Next Big Thing", ' nobody is going to make that connection.