RE: Adaptive images

Another thing that comes to mind would be only applicable in some cases
4. the author specifies <img src="bitmap.ext" vectorize="blurAndTrace"> and trusts the browser to use any of a variety of edge-tracing algorithms (such as in Chapter 21 of http://tavmjong.free.fr/INKSCAPE/MANUAL/html/ ).  No, it wouldn't work well for complex photographic bitmaps but for the 10% - 50% of images on the web (based on a quick count of images returned to google image searches for "hand", "face" and "building") that *should* have been originally cast as vector images, but weren't, an author might be able to trust the browser to do a reasonably scalable on-the-fly vectorization. The topic sort of arose a few years ago on this list and was contentious at best.  While I can appreciate the argument that if the author cares enough about scalability, and if the image really is "vectorable" (a nuance of distinction between "vectorable" and "vectorizable" is perhaps relevant here), the growing amount of reusable and openly licensed pictorial content on the web (much of which is vectorable) means that a use case for having the viewer do the work rather than the author can be made.

regards
David

________________________________________
From: public-html-request@w3.org [public-html-request@w3.org] On Behalf Of Simon Pieters [simonp@opera.com]
Sent: Monday, May 30, 2011 10:07 AM
To: public-html@w3.org; Dominique Hazael-Massieux
Subject: 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 15:54:36 UTC