Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Sizing: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
This page is an in-progress attempt of [[User:Jonathan_Watt|mine]] to make sense of viewport sizing for SVG content (the sizing of the rectangular area the SVG is given to draw into). You'd think it would be simple, what with one 'width' and one 'height' attribute. Unfortunately, there are a lot of other things to consider too, such as different unit types, omitted attribute(s), the CSS 'width', 'height', 'min-width', 'min-height', 'max-width', 'max-height' and 'background-image' properties, the 'viewBox' attribute, intrinsic width, height and aspect ratio, and whether the SVG is rendering standalone, embedded inline or embedded by reference. All add to the fun. | This page is an in-progress attempt of [[User:Jonathan_Watt|mine]] to make sense of viewport sizing for SVG content (the sizing of the rectangular area the SVG is given to draw into). You'd think it would be simple, what with one 'width' and one 'height' attribute. Unfortunately, there are a lot of other things to consider too, such as different unit types, omitted attribute(s), the CSS 'width', 'height', 'min-width', 'min-height', 'max-width', 'max-height' and 'background-image' properties, the 'viewBox' attribute, intrinsic width, height and aspect ratio, and whether the SVG is rendering standalone, embedded inline or embedded by reference. All add to the fun. | ||
The affect of the CSS properties is fairly well defined. An important question to answer is, what part do the SVG 'width', 'height' and 'viewBox' attributes play, and how do they interact with the CSS properties? It has [http://www.w3.org/TR/SVGMobile12/coords.html#InitialViewport become clear] that SVG is to be treated as a [http://www.w3.org/TR/CSS21/conform.html#replaced-element replaced element] in CSS contexts. It has also become clear that the intrinsic dimensions that the SVG must pass to the CSS replaced element algorithm are to come from the SVG 'width', 'height' and, possibly, 'viewBox' attribute. | |||
Currently there are two primary candidate approaches to sizing SVG content; (1) map the 'width' and 'height' attributes into style; (2) treat root 'svg' elements as "replaced elements" in CSS terms. The former approach would have the advantage of being the most intuitive for authors. The latter approach solves the problem of the 'display' property (i.e. [http://lists.w3.org/Archives/Public/www-svg/2005May/0022.html what you do with |display:inline;| on SVG]), and unless the user sets only one of the CSS properties 'width' and 'height' on the SVG while also having 'width' and 'height' attributes, they won't notice a difference to the former approach (well, as long as percentage attribute values are intrinsic). | |||
The former approach would have the advantage of being the most intuitive for authors. The latter approach solves the problem of the 'display' property (i.e. [http://lists.w3.org/Archives/Public/www-svg/2005May/0022.html what you do with |display:inline;| on SVG]), and unless the user sets only one of the CSS properties 'width' and 'height' on the SVG while also having 'width' and 'height' attributes, they won't notice a difference to the former approach (well, as long as percentage attribute values are intrinsic). | |||
<h2>Common ground</h2> | <h2>Common ground</h2> | ||