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: Ben Darlow <ben@kapowaz.net>
Date: Fri, 28 Mar 2008 09:01:46 -0500
Message-Id: <D514C3C0-42B4-4286-A499-ED46DD86FD35@kapowaz.net>
To: www-style@w3.org

On 27 Mar 2008, at 23:00, Brad Kemper wrote:

>> [...]
>> 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;
>> }
> 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 */
> 	max-width:1000px;
> 	min-width:400px;
> 	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.

That's true; I'm basically going on the terminology that the original  
paper used, which to me was ambiguous as to which is the specific  
method they used and the general intention of the technique. I  
suspect seam-carve would be the better term to use in either case.

> 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).

That all sounds very acceptable to me; repurposing max/min-width for  
this would make a lot of sense, as would resize-method (which could  
perhaps allow other resizing methods such as cropping without  
resorting to background clipping).

Received on Friday, 28 March 2008 14:02:37 UTC

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