Re: Adaptive images

On May 31, 2011, at 6:43 PM, Tab Atkins Jr. wrote:

> On Tue, May 31, 2011 at 11:28 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>> From: Henri Sivonen [mailto:hsivonen@iki.fi]
>>> On Tue, 2011-05-31 at 06:48 -0700, Leonard Rosenthol wrote:
>>>> Correct.  And that's fine for web/server-hosted content.
>>>> 
>>>> However, consider an EPUB3 file where there is no negotiation going on.  So you'd (most likely) need something in the <img> tag that would list the alternatives and then have those connected (via id/name) to CSS queries so the UA would know which one to pick.
>>> 
>>> If you've transferring the whole epub bundle to the end user anyway, why
>>> bother having multiple versions of images instead of having a high-res
>>> image and letting the client downsample? Are you optimizing client CPU
>>> and RAM use instead of the epub bundle size?
>> 
>> Because alternates are _NOT JUST_ about resolution - they can also be completely different images based on layout.  For example, the image that I want to show in portrait may not be the same as the one that I show in landscape - so I would have both versions in the documents.
> 
> This is no longer about multiple versions of the same image, then -
> it's about multiple different images, based on your dynamic layout.
> This should be handled by CSS, in the manner described earlier in this
> thread (using the 'content' property, which currently isn't powerful
> enough to satisfy this use-case, but *should* be).


<chair hat off>

CSS (and CSS media queries) are sufficient for CSS-applied images. For content images (<img>, <input type=image>, <video poster>, perhaps others that I am not thinking of), it's not really sufficient. Here are a few issues:

1) The src image will still be loaded even if CSS substitutes a different image with the content property, resulting in a double load.
2) content in most browsers does not give a user experience exactly equivalent to the image element.
3) When doing things like dragging an image out or saving it, it might not even be the obvious choice to use the currently displayed image.

While some use cases for this are dynamic layout choices, I think the key use case is UI scaling. On some popular platforms, a CSS pixel is one device pixel. On others, it is 2 device pixels. Still other ratios are sometimes seen. Let me give an example where physical screen size is not an issue. If I want my site with images to look great on a display like the iPhone 4's Retina display, I need to provide images that are 2x resolution, and then give them a height/width to take them down to half, to account for the scale between CSS pixels and device pixels. Then I can take advantage of the extra sharpness. But on an iPhone 3G, I really would not want to do that - it would be a huge waste of bandwidth to send a 2x image, and it might look worse scaled down than a properly made 1x scaled image. I don't think content today gives an adequate solution for this use case.

I don't think any solution along the lines of "read from server and stop early" cuts it either, because latency is high on modern cellular networks in proportion to the bandwidth, so if I cut off the server connection early, my incoming bandwidth has already been wasted.

I also don't think a solution that requires the server to make the choice by sending it a special header is very good. It is not usable in server-free environments such as widgets or ebooks. While these are not strictly speaking "the Web", I don't think it's great to design solutions that excludes them if we can help it.

And finally, I am leery of solutions using magical file naming conventions.

Given all that, I am not sure what the best solution is.

Regards,
Maciej

Received on Wednesday, 1 June 2011 02:10:09 UTC