W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

SVG-as-an-image and scaling the SVG by default

From: Jonathan Watt <jwatt@jwatt.org>
Date: Tue, 01 Feb 2011 17:34:48 +1300
Message-ID: <4D478D68.6000501@jwatt.org>
To: www-svg <www-svg@w3.org>
Hi WG,

The SVG spec says (roughly speaking) that when an SVG doc is embedded by
reference by an element with an established width and height, the SVG doc should
use that width and height instead of the width and height attributes on its root
<svg> tag:

  http://www.w3.org/TR/SVG11/coords.html#ViewportSpace

That's the scenario assumed for what follows.

The rules summarized above may make sense when the embedding element is
<object>, <iframe> or <embed>, but Mozilla (and apparently only Mozilla) has
also implemented it this way for <img> too, as per the letter of the spec.

One of the consequences of obeying the letter of the spec here is that SVG that
has a width and height attribute but no viewBox attribute will be "clipped" if
the width or height of the embedding element is different to the width or height
specified in the SVG. There are a couple of issues with this behavior when using
HTML <img> or SVG <image> etc.

1) Authors using <img> and <image> are accustomed to having their images scale
if they specify width/height on their <img>/<image> tag. Therefore Mozilla's
behavior is likely counter to what people will expect or want.

2) In the case that the author doesn't control the SVG (or for some other reason
can't easily add a viewBox attribute to it) it is then pretty impractical in
Mozilla to obtain the scaling you would get with a raster image. Conversely, for
implementations with the opposite behavior (the browser scales the SVG instead
of clipping it) it is pretty easy to clip it using the clip property.

Given the above, and given the fact that Opera and Webkit (the existing browser
implementations supporting SVG-as-image) and soon to be IE all do scaling
instead of clipping (or, more precisely, overriding the SVG's width/height), I'm
wondering if anyone has any reasons why Mozilla shouldn't do the same. I'd quite
like to give authors compatible behavior here, so if there aren't good reasons
to go with the letter of the spec for SVG-as-image I'd like us to break it too,
and let's fix the spec later.

Assuming Mozilla changes and we change the spec to reflect what everyone does,
it would seem like a good idea to introduce a property called, say,
'embed-sizing', which can be used on the embedding element/the root <svg>
element to say "when embedding images/me, scale/clip me". Hopefully that should
give all the functionality promised by the current spec, but with more intuitive
default behaviors.

Jonathan
Received on Tuesday, 1 February 2011 04:35:21 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT