- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Wed, 25 Jan 2012 15:39:13 +0000
It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. On 25 January 2012 15:27, Markus Ernst <derernst at gmx.ch> wrote: > Am 25.01.2012 15:07 schrieb Matthew Wilcox: > > In fact, please just read the blog post Bruce Lawson (Opera Software) >> made summarising the last few months of effort on this, and his proposal >> for a mark-up level solution (which I'm in broad support of, though there >> are a lot of knotty issues with any potential solution - as can be seen by >> the volume of blog-posts, comments, and articles on the topic): >> >> http://www.brucelawson.co.uk/**2011/notes-on-adaptive-images-**yet-again/<http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/> >> > > I would like to propose a use case different from the ones in this > blog-post: Scaled images. > > The more physical screen densities improve, the less image pixels actually > correspond to device pixels, and thus scaling images will be less a > problem. E.g., designers might want to define an image size in em units > rather than in px, so it keeps its relation to the text size. > > This use case requires a negotiation based on the dimensions of the image > element rather than the dimensions of the media. It would be nice if a > solution to the responsive images problem would address this use case, too. > AFAICS this would require a more general syntax for the conditions. > > On 25 January 2012 13:42, David Goss<dvdgoss at gmail.com> wrote: >> >>> I'm proposing this (adapted from Bruce Lawson's<picture> idea, and >>> similar >>> >>> to how the<video> element works): >>> >>> <adaptiveimg> >>> <img src="sweater-small.jpg" alt="Blue v-neck sweater in soft wool"> >>> <source src="sweater-medium.jpg" media="(min-width: 300px) and >>> (max-width: 450px)"> >>> <source src="sweater-large.jpg" media="(min-width: 451px) and >>> (max-width: 600px)"> >>> <source src="sweater-huge.jpg" media="(min-width: 601px)"> >>> </adaptiveimg> >>> >> > If the introduction of a new element is an option, it could also be the > other way around, as image maps work: > > <img src="default.gif" srclist="mySrcList" id="myImg" alt="My responsive > image" style="width:5em;height:auto"> > <srclist id="mySrcList"> > <source src="low.gif" cond="[condition]"> > <source src="high.gif" cond="[condition]"> > </srclist> > > To address my above use case, I replaced the media attribute with a more > general cond attibute, which can take a condition with a selector and a > rule. The selector can be the keyword "media" or a CSS selector, and the > rule either a min-width and/or max-width declaration, or some statement > about network speed or whatever, such as: > > <source src="small.gif" cond="#myImg{max-width:49px}"> > <source src="medium.gif" cond="#myImg{min-width:50px;**max-width:99px}"> > or: > <source src="small.gif" cond="#wrapper{max-width:**320px}"> > or: > <source src="small.gif" cond="media{max-width:320px}"> > or: > <source src="slow.gif" cond="media{network-speed:[**some slow value]}"> >
Received on Wednesday, 25 January 2012 07:39:13 UTC