W3C home > Mailing lists > Public > public-html@w3.org > June 2011

Re: Adaptive images

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 1 Jun 2011 12:44:42 +0900
Message-ID: <BANLkTinLHRXMm6RaAYE-kZ=-dd90M5b+HA@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Henri Sivonen <hsivonen@iki.fi>, Karl Dubost <karld@opera.com>, "public-html@w3.org" <public-html@w3.org>
On Wed, Jun 1, 2011 at 11:08 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On May 31, 2011, at 6:43 PM, Tab Atkins Jr. wrote:
>> 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.

#2 is a CSS issue that should be fixed.  #3 is just a QoI issue; I
think it's relatively obvious that, once the 'content' property can
duplicate replaced elements, saving/dragging an image should use the
generated content.  #1 is a harder problem because of layering, and I
dunno what to do about that.


> 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.

Right.  I was specifically talking about the "use different images in
different layouts" case, rather than the "multiple resolutions of the
same image" case.  The latter is conceptually simpler, but still very
hard to solve. :\

~TJ
Received on Wednesday, 1 June 2011 03:45:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:32 GMT