Re: Adaptive images

Use-cases I think are interesting:

1. Web app wants icons/buttons match device pixels 1:1, even if this means  
physical size will vary slightly. That's what Android does with  
ldpi/mdpi/hdpi assets:
    http://designbycode.tumblr.com/post/1127120282/pixel-perfect-android-web-ui

2. User on touchscreen device can use standard zoom gesture to see more  
detail in the image, rather than tapping to open popup/lightbox with a  
larger version (as such UI is ill-suited for small-screen devices and  
fails to take advantage of easy zooming).
    Similarly it would be nice if zoomed-out overview of the page  
downloaded lower-res images to show page quicker.

3. User on desktop with low-dpi screen can print the page with  
high-resolution images

4. User on bandwidth-limited connection (3G/roaming) may prefer most  
images to be smaller and only see selected images in full quality

5. Memory-constrained mobile device may choose to use low-res images even  
when it has high-dpi screen (memory pressure may vary depending on number  
of tabs/apps open, number of images on the page)


I've ignored use-case of having different image for portrait/landscape  
layout (media query + content: or clip() might be good enough for this).



Existing solutions:

- media queries + content:
   Can't help with #4, #5. I think currently zoom level does not affect  
media queries, so #2 may not be possible (yet?).
   The syntax is very noisy (there's need to select appropriate img  
element). Replaced content is not guaranteed to behave like the original  
image. Async loading of CSS and <img> can result in double download (which  
isn't simply quality of implementation issue, because parallel download of  
CSS and images is a good implementation in other circumstances)

- SVG.
   Could partially solve #1, #2, #3, but it can't help with photos and it's  
hard to guarantee crisp device-pixel-aligned lines in SVG.
   I'm also concerned that authors may want to use bitmap images even in  
cases where SVG could work, due to their preferred design tools and skills.

- multi-image formats, such as ico/icns/tiff.
   Could solve #1, #2, #3, but it's a worst-case scenario for bandwidth.

- progressively downloaded images (interlaced PNG, progressive JPEG) help  
a little with #4, but I doubt whether connection can be effectively  
aborted for it to save bandwidth.
   This solution don't allow authors to provide properly anti-aliased and  
tweaked low-res versions of the image.

- proxies such as Opera Turbo and proxies employed by mobile ISPs — solves  
#4 well and #5 poorly, but ISP proxies can't help with HTTPS and are  
terrible at offering selective download of higher-resolution images (e.g.  
my ISP injects javascript that doesn't work and breaks XML pages).

- HTTP negotiation
   Currently can only solve #1 and partially #4 (with lots of shoddy  
assumptions about UAs and networks). Not suitable for non-HTTP "pages"  
such as widgets, epub.
   For other cases UAs would have to include information about DPI and  
filesize preferences, rely on server interpreting these correctly, use  
Vary header correctly, and re-request images when  
resolution/bandwidth/memory changes.



I think it's also worth to mention lowsrc:  
http://msdn.microsoft.com/en-us/library/ms534138(v=vs.85).aspx and that  
Tumblr implements such thing using JavaScript.


I'm in favour of declarative client-side approach, as information about  
zoom, bandwidth and memory is available on the client and these properties  
may change after page is downloaded.

I'm wondering whether addition of lowsrc and highsrc attributes would  
satisfy the use cases:

<img lowsrc="low-quality image <= 100dpi" src="regular ~100dpi image"  
highsrc="high-quality >100dpi image">

It has advantage of having very simple syntax, and it's also  
image-format–agnostic.

The tricky issue here is knowing CSS pixel dimensions of low/high  
resolution images when <img width/height> is absent. Either width/height  
would have to be mandatory for lowsrc/highsrc to work or additional  
information is needed, maybe using attributes such as lowdpi/highdpi,  
sizes or pixel-ratios?


Another idea is to make src a space-separated list of URLs and (ab)use  
fragments for selection of resolution:

<img src="regular.jpg#100dpi small-image.jpg#50dpi full-image.jpg#300dpi">  
<!-- alternatively #@3x rather than #300dpi -->

Thanks to hash it's fully backwards-compatible and allows author to choose  
which size is the default one. Syntax is relatively simple, very compact  
and doesn't require new attributes/elements.


-- 
regards, Kornel Lesiński

Received on Thursday, 2 June 2011 13:11:17 UTC