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

Re: Adaptive images

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 1 Jun 2011 14:43:00 +0200
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, 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: <20110601144300854717.84bf4fc7@xn--mlform-iua.no>
Tab Atkins Jr., Wed, 1 Jun 2011 12:44:42 +0900:
> On Wed, Jun 1, 2011 at 11:08 AM, Maciej Stachowiak
>> 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.

#1 can be considered a use case where "graceful up-gradation" (a.k.a. 
'augmentative authoring')  should be applied. Using the CSS generated 
content would be precisely that kind of authoring technique. The double 
load problems can be minimized by:
 * EITHER simply omitting the @src attribute completely, leaving the 
choice of image resource to CSS ... (this is currenlty considered 
invalid, but should eliminate the double load completely) 
 * OR by simply accepting that the highrez devices *have* to perform a 
double load - as long as highrez devises are in minority, that should 
be reasonable.

Alternatively, one could consider it a "graceful degradation" use case, 
and go for using nested <object> elements, where the outer object 
element contains a highres image that only the highrez UAs will use, 
and the nested object contains a lower rez image. For graceful 
degradation with the object element I believe that only the outer 
element is fired, if the UA support the image format it uses.

The problem with graceful degradation is how to control which UAs get 
the "degraded" image and which one get the "upgraded" image. This is a 
general problem that <object> has - to *only* rely on the MIME type is 
to simplistic, it does not give enough control. May be the @media 
attribute that Mathias and Charles were discussing,[1] could be put to 
use on the object element, in order to negotate this?

[1] http://www.w3.org/mid/op.vwavjud5wxe0ny@widsith.local
Leif H Silli
Received on Wednesday, 1 June 2011 12:43:36 UTC

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