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

Re: Adaptive images

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 31 May 2011 20:57:17 -0700
Cc: Leonard Rosenthol <lrosenth@adobe.com>, Henri Sivonen <hsivonen@iki.fi>, Karl Dubost <karld@opera.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <029D6B7E-C7E3-47F6-80F6-320B03294215@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On May 31, 2011, at 8:44 PM, Tab Atkins Jr. wrote:

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

So, that's a little weird - the image you get when dragging out depends on the resolution of the system you view it on. I don't know if that's right, or you should always get the high-rez version, or always the low-rez version, or what. Only the approach you suggest lends itself to the content element.

> #1 is a harder problem because of layering, and I
> dunno what to do about that.

Yeah, I think that's the hard one. I suspect it can only be fixed with some changes at the HTML level. There's also the related problem of when the load event fires on an img in this situation and on its containing document..

Now, if required HTML changes were limited to <img>, that would not be so bad, but it's complexified by the other constructs in HTML that can reference images.

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

Indeed. One "solution" is to have all images be CSS images instead of content images, but I think that's a poor way to handle true content images.

Received on Wednesday, 1 June 2011 03:57:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:14 UTC