W3C home > Mailing lists > Public > www-svg@w3.org > May 2008

Re: Source-image offset/dimensions control for the image element

From: Erik Dahlström <ed@opera.com>
Date: Tue, 13 May 2008 10:16:34 +0200
To: Helder Magalhães <helder.magalhaes@gmail.com>, www-svg@w3.org
Message-ID: <op.ua22lw08gqiacl@gnorps.palace.opera.no>

On Mon, 12 May 2008 15:12:55 +0200, Helder Magalhães  
<helder.magalhaes@gmail.com> wrote:

> Sorry for personally replying to the original message - wrong option...  
> :-(
> ---------- Forwarded message ----------
> From: Helder Magalhães <helder.magalhaes@gmail.com>
> Date: Mon, May 12, 2008 at 2:08 PM
> Subject: Re: Source-image offset/dimensions control for the image element
> To: Erik Dahlström <ed@opera.com>
> The whole idea sounds great! :-)
>  >  In SVG it's only possible to use the 'preserveAspectRatio' attribute  
> to
>  > control the position for raster images. The 1.1 spec says that when an
>  > <image> element references a raster image the implicit 'viewBox' has  
> a value
>  > of "0 0 raster-image-width raster-image-height". If there was a way of
>  > controlling the implicit viewBox it would be possible to draw raster  
> sprites
>  > more efficiently.
>  Being able to control the viewbox attribute would be, in my opinion,
>  powerful enough to achieve desired behavior while staying familiar to
>  SVG authors - CSS's background properties seem somehow unfamiliar (in
>  name and in concept) from the SVG specification.

Though perhaps it could be solved in another way such that it's possible  
to control the viewbox for referenced svg images too, for the cases where  
there is no viewbox specified in the referenced svg. For example through  
introducing a new property/attribute, e.g. 'override-viewbox'.

>  >  It is possible to control all of this in SVG, using for example the  
> clip,
>  > mask or pattern features. However, each of these comes at the price of
>  > additional processing, since they are meant to cover more advanced  
> use-cases
>  > as well.
>  It also seemed to me, at a first glance, that "clip" would be
>  appropriate.

Yes, clip is the most fitting of these. However a drawback is that you  
cannot then specify percentages in the clip property. In one scenario  
there is a wish to reference a library of images which have various sizes,  
and to only draw a certain portion in the middle of each such image. The  
other thing is that the values for the clip property are in userspace  
coordinates, where in the case I'm thinking of it makes more sense to be  
able to specify values in the coordinatespace of the referenced image,  
that is in pixels, or percentages relative to the pixel size of the  
referenced raster image.

> Isn't the "price of additional processing" an
>  implementation detail?

Possibly the processing requirements would be the same if the userspace  
coordinate system is exactly the same as a screen-based pixel coordinate  
system. In general yes, how expensive it is depends on the implementation.

> If the implementation treats "clip" directly
>  applied to a raster image as a special case, it could correspond to
>  the behavior achieved using "viewbox" or equivalent mechanism... Or am
>  I missing something?

Yes, that could be one way of dealing with this. It's only a partial  
solution though, unless coupled with a way of doing percentages and  
raster-coordinatesystem values.

>  On the other hand, maybe this could require implementations to catch
>  up (don't know if any does this already) and/or some implementation
>  notes to be added to the SVG specification in order to perform some
>  evangelism on the subject (for both content and implementation
>  people).

Indeed the 'clip' property seems to not be used much in content.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 13 May 2008 08:15:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:13 UTC