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

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

From: Tony Schreiner <tonyschr@microsoft.com>
Date: Thu, 10 Feb 2011 20:46:55 +0000
To: Jonathan Watt <jwatt@jwatt.org>, Robert O'Callahan <robert@ocallahan.org>, www-svg <www-svg@w3.org>
Message-ID: <B20868C1F6435540A97DBB6B05F18F2517DAA39D@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
We need to be careful here... There are at least three different sizing behaviors that browsers are using when embedding SVG in <img>, not counting complex scenarios.

1) Opera. For <img> embedding only Opera introduces a viewBox if one isn't present, derived from the width/height attributes if they are non-percent values. This does not appear to be in any spec, but is outlined in a proposal at http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html.

2) Webkit. For <img> embedding Webkit stretches the SVG content to fit the bounds of the image and ignores the viewBox. Percent-sized content is doing something else; I'm not sure what.

3) Firefox 4. As you mention the current Firefox 4 betas seem to correctly implement section 7.2 of the SVG 1.1 specification for sizing within <img>.

IE9 Beta scaled SVG content in <img> most similarly to Webkit, but only because the sizing logic was incomplete. In particular we had not yet implemented section 7.2 for images or for other embedding types such as <object> and <embed>.

For IE9 RC, just released today, we looked at the sizing behavior across browsers and considered matching Opera's behavior of introducing a viewBox for <img> only. But because this was not part of any specification and because of the other sizing inconsistencies we decided to follow the letter of the SVG spec. There may be a bit of irony here, as Firefox's choice to follow the spec was one factor we considered in whether or not to follow Opera's behavior.

Here's a sample page which demonstrates some of the differences in <img> sizing across browsers for three core scenarios: http://www.tonyschr.net/svg/ImageScaling.html

- Tony Schreiner

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Jonathan Watt
Sent: Monday, January 31, 2011 8:35 PM
To: www-svg
Subject: SVG-as-an-image and scaling the SVG by default

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 Thursday, 10 February 2011 20:47:31 GMT

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