RE: Adaptive images

Lowsrc/highsrc is interesting, but limiting because it only gives you two options.

The # syntax is (as you note) a bit abusive.  We should be moving away from such constructs that require "sub-parsers".

The other issue that you raise, that will need to be solved, is the "how to compute the image resolution".  You need to know not only physical resolution but also effective resolution and which one get used in which case.  

Leonard

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Kornel Lesinski
Sent: Thursday, June 02, 2011 9:11 AM
To: public-html@w3.org
Subject: 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 15:05:10 UTC