W3C home > Mailing lists > Public > www-style@w3.org > March 2008

Re: Retargeted images redux: how it might actually be used on the web

From: Brad Kemper <brkemper@comcast.net>
Date: Thu, 27 Mar 2008 21:00:56 -0700
Message-Id: <2983C6F9-4BB9-4291-861A-0E0D8E1C0CFB@comcast.net>
Cc: www-style@w3.org
To: Ben Darlow <ben@kapowaz.net>

On Mar 27, 2008, at 3:32 PM, Ben Darlow wrote:

> Previously (http://lists.w3.org/Archives/Public/www-style/2008Mar/ 
> 0324.html) I discussed the subject of retargeted images as a CSS  
> property, which could be a useful way of flexibly incorporating  
> photographic or complex images into layouts where images can't  
> always be constrained to a given size. Considering my poor timing  
> to suggest this at the same time as David Hyatt posted his long  
> list of very interesting feature proposals based on work with  
> WebKit, it's not too surprising that my suggestion didn't really  
> register on the radar.

Hey Ben,

I read your original post and followed your links, and thought it was  
an amazing technology. I think I saw this a couple years ago, but  
forgot about it. I think you are right about waiting for a break in  
the list activity to propose something new...

> [...]
> The way I envisage that such a technique could be implemented would  
> require a new CSS attribute for image elements, for instance:
> #heading img {
> 	retarget-direction: horizontal;
> 	retarget-max-width:1000px;
> 	retarget-min-width:400px;
> }
> The retargeting can be applied in both axes, so the value of  
> retarget-direction could be horizontal, vertical or both. The  
> attributes for maximum and minimum width would be used to prevent  
> artefacts which tend to occur when an image is retargeted to  
> extreme sizes (both small and large). An image element which is  
> being retargeted would have a block display mode, and would  
> automatically expand to the full width of its containing element.

Mind if I take a stab at making it simpler? Images have an intrinsic  
width, but can be resized via width and height, and can have max- 
width and max-height (which I'm sure you know). It seems to me that  
these would be sufficient for controlling the level to which you  
would allow the retargeting to take place. If you didn't it carved up  
smaller than 400px across, then just don't let it get smaller than that.

I think the big step would be to have something that told the UA how  
to resize the image when it is sized to something different from its  
intrinsic width or height (such as choosing between "seam-carve" and  
"stretch". For instance:

#heading img {
	width:100%; /* stretches to container width */
	resize-method: seam-carve;

Personally I like "seam-carve" better than "retarget", because it  
sounds more descriptive. When I read "retarget" I start thinking of  
anchor targets.

I think something like this would be pretty cool, and would have a  
good fallback method for UAs that didn't support it (they would just  
stretch the image in or out). In theory you could also have "resize- 
method: crop", but that would be more complicated, because you would  
then need to also specify an anchor point that did not move (although  
I suppose "center" could be the default).

> Attempting to implement this as a patch for any of the open source  
> browsers out there is really a task beyond me,

Yeah, me too. I'm still waiting for a browser to start supporting  
auto-hyphenation, something it should be able to easily do without  
author intervention (or maybe with a simple property an author could  
set to false to disallow it). I mean seriously, even PageMaker had  
auto-hyphenation, what, about 15 or 20 years ago?

> but if anybody is interested at least one individual has already  
> implemented the technique using the SDL library (http:// 
> kometbomb.net/2007/09/04/image-retargeting/). I would imagine that  
> a native implementation in one of the modern browsers would be able  
> to perform such transformations vastly more quickly than the  
> alternative (Flash, e.g. rsizr.com).
> All comments and suggestions welcomed!
> ~B
Received on Friday, 28 March 2008 04:01:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:35 UTC