- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 18 Jun 2015 14:05:05 +0200
- To: www-style@w3.org, www-svg@w3.org
fantasai: ... >[none] -> no intrinsic size >viewBox -> intrinsic aspect ratio >width -> intrinsic width >height -> intrinsic height only >width+height -> intrinsic width, intrinsic height, and (derived) intrinsic aspect ratio >width+viewBox -> intrinsic width, (derived) intrinsic height, intrinsic aspect ratio >height+veiwBox -> (derived) intrinsic width, intrinsic height, intrinsic aspect ratio >width+height+viewbox -> intrinsic width, intrinsic height, intrinsic aspect ratio >I'm not really sure what happens when the aspect ratio conflicts with the >width/height ratio, but in any case, all of this should be specified clearly >by the SVG spec, and if it's not, it needs to be specified there. The CSS >specs (Images and Backgrounds) are already very explicit about what happens >with all combinations of intrinsic {aspect ratio, width, height}. The viewBox is mainly intended for internal aspects of the SVG document, the user coordinate system in use. SVG 1.1.2 does not mention it at all for the determination of the initial viewport: http://www.w3.org/TR/2011/REC-SVG11-20110816/coords.html#ViewportSpace SVG tiny 1.2 or the current draft for SVG 2 do not mention viewBox for the determination of the initial viewport either. In general always and only width and height determine the size (if not provided, they are 100% of the viewport, the SVG should be rendered in, what implicates, that if there is an element with a CSS box with some known size around it, the SVG viewport aligns with this. Additionally preserveAspectRatio specifies, how to scale the viewBox into the available viewport, this implicates, that the initial viewport is already known, before viewBox is considered. The viewBox itself does not imply any information about the aspect ratio of the initial viewport for the SVG content. Especially if preserveAspectRatio is set to 'none', obviously there is no such relation intended by the author to be meaningful. This scaling of the viewBox into the initial viewport can implicate, that parts of the SVG outside the viewBox are visible on the viewport as well or not all of the content inside the viewBox becomes visible in the viewport. To resume, the viewBox is not related to the size of the SVG. If noted, it only determines some area of the canvas, that needs to be transformed to be visible in the initial viewport for the SVG content. I think, some viewers use own rules, if the size of the viewport for the SVG content is not known either (what effectively means, it is not known, how an intrinsic size of 100% for width and height has to be presented), in such a case the viewBox might be desireable to determine somehow the aspect ratio or even the size of the displayed SVG, if not specified by the embedding format. Typically for authors and users it could be useful, to take into account preserveAspectRatio (if not set to none) and viewBox in case the size of the viewport for the SVG is not known. For example, typically an author would assume, that if the aspect ratio is conserved and the viewBox is present, that the arbitrarily created viewport at least aligns with the viewBox instead of creating a viewport of arbitrary aspect ratio, not related to the available information with the the consequence, that typically the SVG document is unneccesarily scaled down to fit the viewBox with defined aspect ratio into the created viewport with arbitrary aspect ratio. But currently such a situation with unknown size of the viewport for the SVG is problemantic/unspecified, if not specified already by the embedding format, therefore in doubt authors need to avoid this. My observation with common viewers is, that they even display problematic things, if the viewport size is completely defined by CSS, Assume for example an element xhtml:figure with the following styling: figure {display: block; width: 20em; height: 20em; flow: left} The content of the figure is an SVG, width and height are 100%, viewBox="0 0 400 800", implicated preserveAspectRatio 'xMidYMid'. Unfortunately several common viewers seem to ignore the height of 100% and present the viewBox area with a width of 20em and a height of 40em (this is 200%, not 100%), with the result of an overlap with other content. Correct would be obviously a height of 20em and the width of the viewBox area is scaled to 10em. But if there is content in the SVG on the left or right of the viewBox, this can be visible, because the viewport of the SVG aligns here with the box of the CSS styled xhtml:figure element with a width of 20em and a height of 20em. Therefore even such simple situations, pretty relevant for authors, are worth to be tested carefully to ensure, that future versions of viewers do something meaningful here for such common use cases to size different SVGs within a text with the same stylesheet dependent on units like em to get 'responsive design/styling'. Not sure, whether such testing is more a task for CSS or SVG, maybe more for SVG, because the viewer determine a wrong scaling from the size of the initial viewport and the viewBox. On the other hand, such a test requires CSS interpretation and embedding within another format. Olaf
Received on Thursday, 18 June 2015 12:05:45 UTC