- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 30 May 2011 15:43:39 +0200
- To: public-html@w3.org
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) (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
Received on Monday, 30 May 2011 13:43:55 UTC