Re: Adaptive images

On Mon, 30 May 2011 15:43:39 +0200, Dominique Hazael-Massieux <dom@w3.org>  
wrote:

> Hi,
>
> CSS Media Queries (combined with <meta name=viewport>) provide a
> reasonable way to create layouts that adapt to the size of the screen of
> the device.
>
> But one aspect that remains difficult to manage in such an approach is
> handling of content images.
>
> Indeed, HTML currently allows to specify only one version of an image as
> an input source, which for raster images means a single resolution of
> image. Sending very large images to devices were the layout (or the
> screen resolution) wouldn't be able to fit them well is in most cases a
> waste of bandwidth. Conversely, sending very small images to very large
> screen doesn't take advantage of the underlying device capabilities.
>
> I've gotten requests many times for a mechanism by which an author could
> point to several sources for a given image that would be selected by the
> client depending on the screen size.
>
> There are server-side techniques to do that (e.g. tinySrc.net), but they
> rely on databases of devices that have to be maintained and which don't
> necessarily scale to all usage.
>
> A client-side mechanism similar to what media queries allow for layout
> would likely prove very useful.
>
> Some ideas on how this could be done:
>
> 1. New @srclist attribute point to list of sources
>         <img src=default.jpg srclist=alternativeSizes alt="Picture of
>         Unicorn">
>         <sourcelist id=alternativeSizes>
>         <source src="big.jpg" media="min-width: 600px" width="600"
>         height="400">
>         <source src="small.jpg" media="max-width: 600px" width="320"
>         height="320">
>         </sourcelist>
>
> (<sourcelist> could maybe be replaced by another existing element?
> <map>? <datalist>? SVG's <switch>?)
>
> 2. New image format that points to alternative resolutions
>         <img src="image.list" alt="Picture of Unicorn>
>        image.list:
>         Content-Type: image/list
>        URI: big.jpg
>         media: (min-width: 600px)
>        URI: small.jpg
>         media: (max-width: 600px)

3. Use a single image that is supports progressive rendering and let the  
UA abort the download when it has downloaded enough (like with <video>).  
The UA can make a new HTTP Range request to download more (like with  
<video>) of the image if the user zooms in. This might have compat issues  
if done without opt-in, but we could introduce it as an opt-in feature  
(e.g. new attribute that points to the big progressive image which lets  
the author choose the fallback behavior).


> (maybe the images list could also be embedded in a <script
> type='image/list'>?)
>
> Advantage of #1 is that the author still gets to define the actual size
> of the images, which means no reflowing when the image get downloaded.
>
> #2 allows to avoid redefining over and over the alternative versions of
> an image.
>
> I guess that only #1 actually requires modifications to HTML; #2 would
> probably be more a matter of writing an IETF draft.
>
> Any suggestions or feedback on this?
>
> I'm planning on adding this message to the HTML.next [1] page once it's
> archived.
>
> Dom
>
> 1. http://www.w3.org/wiki/HTML/next
>
>


-- 
Simon Pieters
Opera Software

Received on Monday, 30 May 2011 14:08:28 UTC