RE: Initial Viewport

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?

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 Wednesday, 12 September 2012 16:29:30 UTC