W3C home > Mailing lists > Public > www-svg@w3.org > September 2012

Re: Initial Viewport

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 12 Sep 2012 21:07:35 -0700
To: Nick Hofstede <Nick.Hofstede@inventivegroup.com>
CC: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <0733DBBD-C2AD-45FF-8D08-F23A5114F7E0@adobe.com>

On Sep 12, 2012, at 6:29 PM, Nick Hofstede <Nick.Hofstede@inventivegroup.com> wrote:

> Correction: I had an invalid testcase (see previous reply). The third one removed the viewBox attribute as well as the width and height attributes.
> When only the width and height attributes are removed, there is no difference with the 100% case.
> The browsers are consistent and correct.
> 
> You seem to suggest that if the parent doesn't specify a viewport, the window dimensions should be used.
> That appears to be the approach of Chrome as well.
> It would be up to the HTML5-WG to define the viewport though, correct?
Well, that is different. If you embed an SVG document with <img>, then this image element establishes the viewport of the SVG element:

<img style="width: 200px, height: 200px;" src="file.svg">

For the case above the viewport is 200px X 200px.

But if you omit the width and height properties, the image element calculates it's boundaries from the referenced image. In our case we have an SVG that has width="100%" height="100%" and depends on the sizing of it's viewport (remember that the image element establishes a viewport). So we have clearly an unsolvable conflict. And then you'll see a difference across browsers. What Firefox does (and we plan to specify it), is setting the image boundaries to 500px X 250px (can someone correct me when I used the wrong numbers?). Then the mutual dependency is solved.

However, consider the case of inline SVG:

<html>
<body>
<svg width="100%" height="100%">
<rect width="100%" height="100%" fill="black"/>
</svg>
</body>
</html>

Then the viewport gets established by the HTML element. Since the default viewport size is 100% by 0% of the window size, you might expect that the inline SVG doesn't get displayed. But this is not the case across browsers. I couldn't test IE, but the other browsers do the following:

* Safari/Chrome: take 100% of the window height and width. The whole screen gets black (minus pattern and margin)
* Opera: take 100% of the viewport width (window width), for height rely on the default 500px X 250px size. Therefor the height is 250px
* Firefox: always rely on the default 500px X 250px size for relative values. SVG is 500px X 250px in size.

I am not sure if any of the browser results is reasonable, but they are clearly inconsistent (IIRC IE had a different behavior then any of the above browsers).

It gets more complicated with the following case:

<html>
<body>
<div style="width: 50%">
<svg width="100%" height="100%">
<rect width="100%" height="100%" fill="black"/>
</svg>
</div>
</body>
</html>

Now the width of the SVG depend on the width of the div box for Opera and Safari/Chrome. The behavior of the height is still the same as above. For Firefox there is no difference (which is at least consistent for FF and the spec, since the div box does not establish a viewport).

In general I would be in favor to harmonize the behavior of inline SVG elements with other HTML elements. But even there are inconsistencies:

<!DOCTYPE html>
<html lang="en">
<head>
<script>
window.onload = function () {
	var canvas = document.getElementById('canvas');
	var ctx = canvas.getContext('2d');
	ctx.fillStyle = "black";
	ctx.fillRect(0,0,100,100);
}
</script>
</head>
<body>
<canvas style="width:100%; height:100%" width="100" height="100" id="canvas"/>
</body>
</html>

(The width and height attribute on canvas don't define the size of the canvas but its resolution, similar to the viewBox attribute on SVG)

For WebKit, the canvas fills the whole Window, which is consistent behavior to the SVG case but still seems to be wrong. Strangely the same happens for Firefox, which is inconsistent with its handling on SVG. For Opera, the width is 100% of the window size and the height is 250px (same behavior as on SVG).

As conclusion: You can not be sure that browser gets the sizing correct (which is not necessarily the issue of browsers, but an issue of the specs). Set the width and height properties on using inline SVG (possibly to absolute values). For embedding with <img>, make sure that your image tag does not rely on the SVG size, but defines the size for the SVG. Or that the SVG does not use relative sizing.

Greetings,
Dirk

> 
> With kind regards,
> 
> Nick
> 
> -----Original Message-----
> From: Nick Hofstede
> Sent: woensdag 12 september 2012 17:13
> To: Dirk Schulze
> Cc: www-svg@w3.org
> Subject: RE: Initial Viewport
> 
> Consider the example where
> <img style="width:400px;height:400px;border:solid black;" src="1.svg"/>
> 
> references an svg with outermost svg element <svg width="100%" height="100%" viewBox="0 0 200 200" version="1.1" xmlns="http://www.w3.org/2000/svg">
> 
> First, to make sure I get the terminology right:
> Viewport: defined by the ancestor, 400px by 400px in this case.
> SVG Boundary: defined by the width and height attributes of the outermost svg element: 100% by 100% in this case.
> ViewBox: defined by the viewBox attribute: 200px by 200 px in this case.
> 
> Your explanation doesn't seem explain why an svg with width and height set to 100% and an svg with width and height omitted should render any different.
> Your explanation doesn't seem to explain what the Viewport should be if the img element doesn't specify a size (but that might be a question for the HTML5 WG).
> It does allow me to pick what the result of this example should look like, I think.
> 
> "If you use (100%, 100%) it just means that the size of the SVG will be (100%,100%) of the viewport." This means - I think - the size of the SVG will be the entire 400px by 400 px of the viewport as defined by the img element.
> "Just imagine viewBox as some kind of transform that scales and transforms the content to let it fit into the boundaries of the SVG element." Translated to this example: this scales the content by a factor of 2 to make the 200px by 200px viewBox fit into the 100% by 100% (= 400px by 400px) SVG boundaries.
> 
> So: the third test case is rendered incorrectly by the browsers and should render like the first?
> 
> Nick
> 
> -----Original Message-----
> From: Dirk Schulze [mailto:dschulze@adobe.com]
> Sent: woensdag 12 september 2012 16:16
> To: Nick Hofstede
> Cc: www-svg@w3.org
> Subject: Re: Initial Viewport
> 
> Hi Nick,
> 
> On Sep 12, 2012, at 1:53 PM, Nick Hofstede <Nick.Hofstede@inventivegroup.com> wrote:
> 
>> The longer I'm looking at this, the more confused I get ...
>> 
>> http://www.w3.org/TR/SVG/struct.html#SVGElementWidthAttribute says that if width or height aren't specified, 100% should be used.
>> However, when I test this (test case attached), there is a difference between referencing an svg with width and height set to 100% and an svg with width and height omitted.
> You are mixing up different things.
> 
> First, width and height attribute depend on the viewport of the SVG element (the window size, or the viewport that gets established of one ancestor). If you use (100%, 100%) it just means that the size of the SVG will be (100%,100%) of the viewport. If you use (200px,200px), then the SVG's size is 200px, 200px on the view port. It does not affect the transformation of the content. The content will still be drawn in the current transformation of the SVG's viewport. This is important, since the boundaries of an SVG element interact as clipping region.
> 
> viewBox defines the coordinates within the SVG element. Just imagine viewBox as some kind of transform that scales and transforms the content to let it fit into the boundaries of the SVG element.
> 
> As example:
> 
> <svg width="400" height="400" viewBox="0 0 100 100"> <rect width="100" height="100"/> </svg>
> 
> The width and height attribute define the boundaries of the SVG. Every content that is outside of the boundaries gets clipped to the boundaries.
> The viewBox defines the coordinates and size of the inner viewport, established by the SVG element itself. In the example it is similar to scaling the content by the factor 4 to make it fit into the SVG boundaries.
> 
> The browsers follow the specification on your examples.
> 
> Greetings,
> Dirk
> 
>> Are all three browsers misinterpreting the specification in a
>> consistent way, or is there a part of the specification I'm missing?
>> (probably the latter)
>> 
>> With kind regards,
>> 
>> Nick Hofstede
>> 
>> 
>> From: Nick Hofstede
>> Sent: dinsdag 11 september 2012 10:23
>> To: www-svg@w3.org
>> Subject: Initial Viewport
>> 
>> Hi,
>> 
>> I'm trying to figure out what the initial viewport should be of an embedded/referenced svg in the following case:
>> -        The parent user agent doesn't provide a size for the referenced svg document (only a coordinate where it should be placed)
>> -        The referenced svg document has width and height on the outermost svg element set to 100%
>> 
>> Browser tests using <img src="test.svg" /> result in creative behavior (the results might be muddied by having to follow CSS rules anyway - the parent user agent I'm thinking of isn't using CSS to specify width/height).
>> 
>> I've been looking at
>> http://www.w3.org/TR/SVGTiny12/coords.html#transform-viewport
>> http://www.w3.org/TR/SVGTiny12/coords.html#IntrinsicSizing
>> 
>> Kind regards,
>> Nick Hofstede
>> 
>> 
>> 
>> Inventive Designers' Email Disclaimer:
>> http://www.inventivedesigners.com/email-disclaimer
>> 
>> --
>> This message has been scanned for viruses and dangerous content by
>> MailScanner, and is believed to be clean.
>> 
>> 
>> Inventive Designers' Email Disclaimer:
>> http://www.inventivedesigners.com/email-disclaimer
>> <1.svg><2.svg><3.svg><referenced.html>
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> 
> 
> ________________________________
> 
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
> 
> 
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> 
> 
> ________________________________
> 
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
Received on Thursday, 13 September 2012 04:08:05 GMT

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